Macro vs Function in C

Macros are error-prone because they rely on textual substitution and do not perform type-checking. For example, this macro:

#define square(a) a * a

works fine when used with an integer:

square(5) --> 5 * 5 --> 25

but does very strange things when used with expressions:

square(1 + 2) --> 1 + 2 * 1 + 2 --> 1 + 2 + 2 --> 5
square(x++) --> x++ * x++ --> increments x twice

Putting parentheses around arguments helps but doesn't completely eliminate these problems.

When macros contain multiple statements, you can get in trouble with control-flow constructs:

#define swap(x, y) t = x; x = y; y = t;

if (x < y) swap(x, y); -->
if (x < y) t = x; x = y; y = t; --> if (x < y) { t = x; } x = y; y = t;

The usual strategy for fixing this is to put the statements inside a "do { ... } while (0)" loop.

If you have two structures that happen to contain a field with the same name but different semantics, the same macro might work on both, with strange results:

struct shirt 
{
    int numButtons;
};

struct webpage 
{
    int numButtons;
};

#define num_button_holes(shirt)  ((shirt).numButtons * 4)

struct webpage page;
page.numButtons = 2;
num_button_holes(page) -> 8

Finally, macros can be difficult to debug, producing weird syntax errors or runtime errors that you have to expand to understand (e.g. with gcc -E), because debuggers cannot step through macros, as in this example:

#define print(x, y)  printf(x y)  /* accidentally forgot comma */
print("foo %s", "bar") /* prints "foo %sbar" */

Inline functions and constants help to avoid many of these problems with macros, but aren't always applicable. Where macros are deliberately used to specify polymorphic behavior, unintentional polymorphism may be difficult to avoid. C++ has a number of features such as templates to help create complex polymorphic constructs in a typesafe way without the use of macros; see Stroustrup's The C++ Programming Language for details.

Macro features:

• Macro is Preprocessed
• No Type Checking
• Code Length Increases
• Use of macro can lead to side effect
• Speed of Execution is Faster
• Before Compilation macro name is replaced by macro value
• Useful where small code appears many time
• Macro does not Check Compile Errors

Function features:

• Function is Compiled
• Type Checking is Done
• Code Length remains Same
• No side Effect
• Speed of Execution is Slower
• During function call, Transfer of Control takes place
• Useful where large code appears many time
• Function Checks Compile Errors

Side-effects are a big one. Here's a typical case:

#define min(a, b) (a < b ? a : b)

min(x++, y)

gets expanded to:

(x++ < y ? x++ : y)

x gets incremented twice in the same statement. (and undefined behavior)

Writing multi-line macros are also a pain:

#define foo(a,b,c)  \
    a += 10;        \
    b += 10;        \
    c += 10;
        

They require a \ at the end of each line.

Macros can't "return" anything unless you make it a single expression:

int foo(int *a, int *b){
    side_effect0();
    side_effect1();
    return a[0] + b[0];
}

Can't do that in a macro unless you use GCC's statement expressions. (EDIT: You can use a comma operator though... overlooked that... But it might still be less readable.)

Order of Operations: (courtesy of @ouah)

#define min(a,b) (a < b ? a : b)

min(x & 0xFF, 42)

gets expanded to:

(x & 0xFF < 42 ? x & 0xFF : 42)

But & has lower precedence than <. So 0xFF < 42 gets evaluated first.

When in doubt, use functions (or inline functions).

However answers here mostly explain the problems with macros, instead of having some simple view that macros are evil because silly accidents are possible.
You can be aware of the pitfalls and learn to avoid them. Then use macros only when there is a good reason to.

There are certain exceptional cases where there are advantages to using macros, these include:

• Generic functions, as noted below, you can have a macro that can be used on different types of input arguments.
• Variable number of arguments can map to different functions instead of using C's va_args.
  eg: https://stackoverflow.com/a/24837037/432509.
• They can optionally include local info, such as debug strings:
  (__FILE__, __LINE__, __func__). check for pre/post conditions, assert on failure, or even static-asserts so the code won't compile on improper use (mostly useful for debug builds).
• Inspect input args, You can do tests on input args such as checking their type, sizeof, check struct members are present before casting
  (can be useful for polymorphic types).
  Or check an array meets some length condition.
  see: https://stackoverflow.com/a/29926435/432509
• While its noted that functions do type checking, C will coerce values too (ints/floats for example). In rare cases this may be problematic. Its possible to write macros which are more exacting then a function about their input args. see: https://stackoverflow.com/a/25988779/432509
• Their use as wrappers to functions, in some cases you may want to avoid repeating yourself, eg... func(FOO, "FOO");, you could define a macro that expands the string for you func_wrapper(FOO);
• When you want to manipulate variables in the callers local scope, passing pointer to a pointer works just fine normally, but in some cases its less trouble to use a macro still.
  (assignments to multiple variables, for a per-pixel operations, is an example you might prefer a macro over a function... though it still depends a lot on the context, since inline functions may be an option).

Admittedly, some of these rely on compiler extensions which aren't standard C. Meaning you may end up with less portable code, or have to ifdef them in, so they're only taken advantage of when the compiler supports.

Avoiding multiple argument instantiation

Noting this since its one of the most common causes of errors in macros (passing in x++ for example, where a macro may increment multiple times).

its possible to write macros that avoid side-effects with multiple instantiation of arguments.

C11 Generic

If you like to have square macro that works with various types and have C11 support, you could do this...

inline float           _square_fl(float a) { return a * a; }
inline double          _square_dbl(float a) { return a * a; }
inline int             _square_i(int a) { return a * a; }
inline unsigned int    _square_ui(unsigned int a) { return a * a; }
inline short           _square_s(short a) { return a * a; }
inline unsigned short  _square_us(unsigned short a) { return a * a; }
/* ... long, char ... etc */

#define square(a)                        \
    _Generic((a),                        \
        float:          _square_fl(a),   \
        double:         _square_dbl(a),  \
        int:            _square_i(a),    \
        unsigned int:   _square_ui(a),   \
        short:          _square_s(a),    \
        unsigned short: _square_us(a))

Statement expressions

This is a compiler extension supported by GCC, Clang, EKOPath & Intel C++ (but not MSVC);

#define square(a_) __extension__ ({  \
    typeof(a_) a = (a_); \
    (a * a); })

So the disadvantage with macros is you need to know to use these to begin with, and that they aren't supported as widely.

One benefit is, in this case, you can use the same square function for many different types.