Why should I avoid macros in C++? [closed]

Macros don’t respect scoping rules and operate at the textual level, as opposed to the syntax level. From this arise a number of pitfalls that can lead to strange, difficult to isolate bugs.

Consider the following well-known example:

#define max(a, b) ((a) < (b) ? (b) : (a))
⋮
int i = max(i++, j++);

The preferred alternative in this case is a function template:

template <typename T>
T max(const T & a, const T & b) { return a < b ? b : a; }

Here’s another case that leads to subtle problems:

#define CHECK_ERROR(ret, msg) \
    if (ret != STATUS_OK) { \
        fprintf(stderr, "Error %d: %s\n", ret, msg); \
        exit(1); \
    }
⋮
if (ready)
    CHECK_ERROR(try_send(packet), "Failed to send");
else
    enqueue(packet);

You might think that the solution is as simple as wrapping the contents of CHECK_ERROR in { … }, but this won’t compile due to the ; before the else.

To avoid the above problem (the else attaching to CHECK_ERROR‘s if instead of the outer if), one should wrap such macros in do … while (false) as follows (and also avoid the duplicate ret):

#define CHECK_ERROR(op, msg) \
  do { \
    int ret = (op); \
    if (ret != STATUS_OK) { \
        fprintf(stderr, "Error %d: %s\n", ret, msg); \
        exit(1); \
    } \
  while (false)

This has no effect on the meaning of the macro, but ensures that the entire block is always treated as a single statement and doesn’t interact in surprising ways with if statements.

Long story short, macros are hazardous at many levels and should thus be used only as a last resort.

Leave a Comment