Why should or shouldn't we prefer a macro that accepts arguments over a function that does the same job?

Question

Following are two programs that give the area of the circle when the radius is passed as argument. But in the first program, macro.c, I am using a macro for the job, while in the second, function.c I am using a function for the job.

I am familiar with the use of functions,and the nuances it takes. But what about the case of macros that accept arguments? When should we prefer them over functions? And when should we avoid them? Which one gives better performance? I know the macro approach will lead to bulky code if the macro is used many times in the program, while for the case of the function, the same function is invoked many times for the job. But beyond this trivial difference, what are the other issues we need to look out for?

//macro.c

#include<stdio.h>
#define AREA(x) (3.14*x*x)

int main(void)
{
    float r1=6.25,r2=2.5,a;

    a=AREA(r1);
    printf("\nArea of circle=%f",a);
    a=AREA(r2);
    printf("\nArea of circle=%f",a);
}


//function.c

#include<stdio.h>
float area(float);

int main(void)
{
    float r1=6.25,r2=2.5;
    printf("\nArea of circle=%f",area(r1));
    printf("\nArea of circle=%f",area(r2));
}

float area(float radius)
{
    return 3.14*radius*radius;
}

While your question seems reasonable from a "let's learn something" standpoint, it's unfortunately not really answerable and therefore off topic for Stack Overflow. There are reasons to use both, and these days most compilers support inline functions, too. — Carl Norum, May 08 '13 at 05:16
This has been asked many times before: http://stackoverflow.com/questions/9104568/macro-vs-function-in-c and http://stackoverflow.com/questions/1616802/when-to-use-function-like-macros-in-c to name a few — Adam Rosenfield, May 08 '13 at 05:16
@BLUEPIXY Thanks to you too.I've noticed that many times you point to something very useful & relevant,but struggle with your English!! — Rüppell's Vulture, May 08 '13 at 05:55

Alok Save · Accepted Answer · 2013-05-08T05:24:30.120

4

A number of flip sides of macro:

With macro you lose all the type safety. The arguments being passed are not typed checked as in case of inline functions.
Since macros are pure textual replacement they may produce Side effects.
An macro might be evaluated more than once and result in errors.

So it is better to just avoid them, Use inline functions instead.

inline functions do have their own share of flip sides:

They are not guaranteed to be inlined per see.

But given the comparison, inline definitely scores over macros.

edited May 08 '13 at 05:24

answered May 08 '13 at 05:16

Alok Save

202,538
53
430
533

And multiple evaluation fail, and worse possibilities for intelligent inlining, etc.., – May 08 '13 at 05:17
@H2CO3 What exactly is multiple evaluation here? – Rüppell's Vulture May 08 '13 at 05:18
@AlokSave Are inline functions in C a post C99 thing?Wikipedia says `Compilers are not obligated to respect this request.` – Rüppell's Vulture May 08 '13 at 05:20
@Rüppell'sVulture: It is a suggestion in terms of actual code inlining but it is most appropriate way to wriggle out of one definition rule and define functions in header files. – Alok Save May 08 '13 at 05:26
1

@Rüppell'sVulture Multiple evaluation is `AREA(++foo)` expanding to `3.14 * ++foo * ++foo` (which, by the way, will not produce the correct answer). – michaelb958--GoFundMonica May 08 '13 at 05:44
@michaelb958 It'll be very nice of you if you can give me link on SO where this issue is discussed in a separate question. – Rüppell's Vulture May 08 '13 at 05:45
@michaelb958 And I would never use something complicated like `AREA(++foo)` for macros, I'll prefer functions instead. – Rüppell's Vulture May 08 '13 at 05:46
@Rüppell'sVulture That isn't SO question fodder; that's basic Googleable preprocessor weirdness. (And what about `AREA(rand() % 16)`? Or `AREA(complicated_calculation(foo, num_of_bars, baz))`? All legitimate use cases that work fine in an `inline` function and fall flat in a macro.) – michaelb958--GoFundMonica May 08 '13 at 05:52
@michaelb958 Thank you.Your comment supplemented the answers to this question well. – Rüppell's Vulture May 08 '13 at 05:53

score 4 · Answer 2 · answered May 08 '13 at 05:19

One reason to prefer functions, particularly external functions in library code, is so you can fix bugs without recompiling everything that uses them. For instance, fixing your bad definition of pi... :-)

The only time I can think to prefer macros is when you're doing generic programming, i.e. you want the same code to work on various different types, or where you want to use arguments to the macro in ways other than as expressions (for instance, having an operator as an input to the macro, or stringifying an argument, etc.).

score 1 · Answer 3 · answered May 08 '13 at 05:49

Adding some more :)

->In C, macro invocations do not perform type checking, or even check that arguments are well-formed, whereas function calls usually do.

->a macro cannot return anything which is not the result of the last expression invoked inside it.

->Since C macros use mere textual substitution, this may result in unintended side-effects and inefficiency due to re-evaluation of arguments and order of operations.

->Compiler errors within macros are often difficult to understand, because they refer to the expanded code, rather than the code the programmer typed.

->Many constructs are awkward or impossible to express using macros, or use a significantly different syntax.

score 0 · Answer 4 · answered May 08 '13 at 05:18

0

Macro will give you better performance but only for small code whereas if you want your funciton to do many things for you then it is beter to use function. The explanation on this link is clear enough

http://www.c4learn.com/difference-between-macro-and-function-in-c-programming.html

If you stil have any doubts i ll try to answer

answered May 08 '13 at 05:18

maddy

109
4
13

Macros *should not* perform better than static inline functions. – R.. GitHub STOP HELPING ICE May 08 '13 at 05:20
@R.. The following paragraph from Wikipedia's `inline function` entry seems to suggest that using inline functions in C seem to carry no guarantee `In various versions of the C and C++ programming languages, an inline function is a function upon which the compiler has been requested to perform inline expansion. In other words, the programmer has requested that the compiler insert the complete body of the function in every place that the function is called, rather than generating code to call the function in the one place it is defined. Compilers are not obligated to respect this request.` – Rüppell's Vulture May 08 '13 at 05:24
Using macros also carries no guarantee. The compiler is free to factor the common code from multiple macro expansions out into a function and generate call instructions to call it. – R.. GitHub STOP HELPING ICE May 08 '13 at 05:51
There is not guarantee that the function would be inlined, but the question is if you should care about it. Maybe you should let your optimizer do what it wants, even if it decides not to inline. Your question is still interesting of course, I understand that it can be frustrating. I have been working with an optimizer that wouldn't inline a `static inline` function that was called only once, and I could not see any reason why. – Gauthier May 27 '13 at 08:48

hem · Answer 5 · 2013-05-08T07:09:43.787

The #define directive specifies a macro identifier and a replacement list.

Redefining a macro previously defined is not legal, unless the new definition is precisely the same as the old.

Eg syntax:

#define identifier replacement-list

#define AREA(x) (3.14*x*x)

AREA(x) is identifier anf (3.14*x*x) is the replacement list

The replacements are done while pre-processing By the end of pre-processig phase, the replacements are complete.

Prior to pre-processing phase:

int main{

      float r1=6.25,r2=2.5,a;
      a=AREA(r1);
      printf("\nArea of circle=%f",a);
      a=AREA(r2);
      printf("\nArea of circle=%f",a);
      return 0;

}

After pre-processing:

int main{

      float r1=6.25, r2=2.5,a;
      a=(3.14*r1*r1);
      printf("\nArea of circle=%f",a);
      a=AREA(3.14*r2*r2);
      printf("\nArea of circle=%f",a);
      return 0;

}

Advantages of MACROS

-> When the code in the replacement-list is less in size, we can use MACROS. Because the replacements are done during pre-processing time, the program doesn't have to shift the controls between functions during run time. And the program execution speed is great.

-> The Function over head is reduced.

Dis-advantages of MACROS

-> The ultimate goal of a programmer is to write programs of lesser size. When the code in the replacement list is more, what happens!! Redundancy of code occurs, which is very bad in the perspective of a good programmers. This is where the functions come in to play.

-> The arguments in the replacement-list aren't type checked.

-> It is not a good programming practice to specify macro arguments that use the increment (++), decrement (- -), and assignment operators (such as +=)

For example, do not pass the following argument to the _toupper macro:

_toupper(p++)

When the argument p++ is substituted in the macro definition, the effect within the program stream is as follows:

((p++) >= 'a' && (p++) <= 'z' ? (p++) & 0X5F : (p++))

Because p is being incremented, it does not have the same value for each occurrence in this macro replacement. Even if you are aware of possible side effects, the replacement lists within macro definitions can be changed, which changes the side effects without warning.

So, everything has its advantaged and dis-advantages :)

Macros are resolved **prior** to compiling the code, that is during pre-processing. — alk, May 08 '13 at 06:23

Why should or shouldn't we prefer a macro that accepts arguments over a function that does the same job?

5 Answers5