3

From Programming in C (3rd edition), page 309

Because macros are directly substituted into the program by the preprocessor, they inevitably use more memory space than an equivalently defined function.

In which sense do macros take more space than an equivalently defined function?

3

A function is identified by an entry point (address) inside the executable code. You use a function from different parts of your code.

If you use a macro, the object code of that macro is substituted in each section of the code where it is called, so you have multiple copies of the same code instead of just one called by reference.

| improve this answer | |
  • So the memory space that is referred to here is the space that the program itself takes in memory and not the space that's used by the program. Is that right? – Kareem Sep 27 '14 at 15:00
  • That's exactly how I see it working. – Cygni_61 Sep 27 '14 at 15:05
  • But this doesn't necessarily mean that a macro would consume more space than a function. The book doesn't assume using a macro multiple times and it also doesn't refer to the space that the program itself takes in memory in any way or another. If you have a good source I'd like to take a look please, Luigi! Thank you! – Kareem Sep 27 '14 at 23:14
  • "The book doesn't assume using a macro multiple times". Yes, they assume it, they just didn't state this assumption. The code to call a function is fairly small. If it is smaller than the code for the function, then having one copy of the function and multiple calls will result in smaller code than having multiple copies of the function code (which is what you get with the macro). – user2623 Sep 28 '14 at 18:54
3

The plain and simple truth is: Macros are NOT stored directly in memory.(during program execution and/or compiling)

What happens is, that, the values are copied from the macro to where you used the macro during preprocessing. When it comes to the compiler they don't even exist, they've been replaced by the preprocessor before they get that far. That is, macros are a preprocessor construct. It's not really important that they do consume more space. the sentence in that book seems kinda preposterous but I don't think it's compulsory for that to be true. It may be (usually is) true but now always.

Now, coming to the war Functions VS. Macros

I have tried to explain everything in a plain and simple and practical manner, it may take some time to gulp done what I'm gonna say. :P

Macros : In order to understand the difference between macros and functions, you must understand macros well enough

So, in a macro, there two possibilities. ==>

A. They themselves call other functions predefined in libraries or elsewhere.

B. They make the use of operators to create a whole new function(al) macro(if I may say so).

NOTE: If you think about it, whenever you use a macro, you end up calling an operator or another (inbuilt or elsewise) function only.

Let's first dive into A below:

#include <stdio.h>

#define printHello printf("Hello")
#define printWorld printf(" World\n")
int main(void)
{   
    printHello;
    printWorld;
}

is more like the below to the compiler

#include <stdio.h>

int main(void)
{   
    printf("Hello");
    printf(" World\n");
}

So, as you can see from the above, that you finally ended up calling a function to implement something done using macros, its visible that when calling functions within macros, the compiler actually ends up calling the function only, and not the macro (as one may expect) hence there would be an overhead of memory storage of macros and that of functions in preprocessing. This is place one where the macros take more space than the functions due to an overhead.

So, from above situation, it's clear that macros calling built-in functions will always be more memory demanding.

Now, let's check out B:

    #include <stdio.h>
    #define square(a) (a * a)
    int main(void)
    {   
        int t[5] = {1, 2, 3, 4, 5}, i;

        for(i = 0;i < 5;i++)
        {
            t[i] = square(t[i]);
        }
    }

Compare the example above to the one below:

#include <stdio.h>
int square(int a)
{
    a = (a * a);
}
int main(void)
{   
    int t[5] = {1, 2, 3, 4, 5}, i;

    for(i = 0;i < 5;i++)
    {
        t[i] = square(t[i]);
    }
}

Same thing, right? Except, in the second, we use a function instead of a macro.

Now think about it. If you make the use of the same function multiple times, you end up using a lot of memory, but then, with the power of functions like malloc() and free() and realloc() we can always put this memory to good use. But, in the case of a macro, you don't get access to any of this. You will end using more memory than you would in a function, because in a function, you can rewrite, reuse, and hence utilise memory better. Moreover, in assembly, loops aren't really possible, hence, when you use a macro, a new variable is created everytime you iterate through the loops and hence, even more memory is used. The above example was just signatory but crucial.

You should try writing a lot more code that can show you the other real benefits of macros and functions. Macros have their uses, but functions are better (usually).

TL;DR: Functions are better, read the whole answer to know why. The book makes the statement sound very rigid and like a hard rule, but the fact is it may not be true every time.

Best of luck understanding memory, and happy coding...

| improve this answer | |
  • The quote from the book is referring to code size. A macro that is called from several places in your code will result in larger code size than the equivalent function. malloc, free, and realloc are not relevant to that process since they deal with run-time heap memory. – user2623 Sep 28 '14 at 19:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .