Why are preprocessor macros evil and what are the alternatives?

Question

I have always asked this but I have never received a really good answer; I think that almost any programmer before even writing the first "Hello World" had encountered a phrase like "macro should never be used", "macro are evil" and so on, my question is: why? With the new C++11 is there a real alternative after so many years?

The easy part is about macros like #pragma, that are platform specific and compiler specific, and most of the time they have serious flaws like #pragma once that is error prone in at least 2 important situation: same name in different paths and with some network setups and filesystems.

But in general, what about macros and alternatives to their usage?

Answer 1

The saying "macros are evil" usually refers to the use of #define, not #pragma.

Specifically, the expression refers to these two cases:

• defining magic numbers as macros

• using macros to replace expressions

with the new C++ 11 there is a real alternative after so many years ?

Yes, for the items in the list above (magic numbers should be defined with const/constexpr and expressions should be defined with [normal/inline/template/inline template] functions.

Here are some of the problems introduced by defining magic numbers as macros and replacind expressions with macros (instead of defining functions for evaluating those expressions):

• when defining macros for magic numbers, the compiler retains no type information for the defined values. This can cause compilation warnings (and errors) and confuse people debugging the code.

• when defining macros instead of functions, programmers using that code expect them to work like functions and they do not.

Consider this code:

#define max(a, b) ( ((a) > (b)) ? (a) : (b) )

int a = 5;
int b = 4;

int c = max(++a, b);

You would expect a and c to be 6 after the assignment to c (as it would, with using std::max instead of the macro). Instead, the code performs:

int c = ( ((++a) ? (b)) ? (++a) : (b) ); // after this, c = a = 7

On top of this, macros do not support namespaces, which means that defining macros in your code will limit the client code in what names they can use.

This means that if you define the macro above (for max), you will no longer be able to #include <algorithm> in any of the code below, unless you explicitly write:

#ifdef max
#undef max
#endif
#include <algorithm>

Having macros instead of variables / functions also means that you cannot take their address:

• if a macro-as-constant evaluates to a magic number, you cannot pass it by address

• for a macro-as-function, you cannot use it as a predicate or take the function's address or treat it as a functor.

Edit: As an example, the correct alternative to the #define max above:

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

This does everything the macro does, with one limitation: if the types of the arguments are different, the template version forces you to be explicit (which actually leads to safer, more explicit code):

int a = 0;
double b = 1.;
max(a, b);

If this max is defined as a macro, the code will compile (with a warning).

If this max is defined as a template function, the compiler will point out the ambiguity, and you have to say either max<int>(a, b) or max<double>(a, b) (and thus explicitly state your intent).

Answer 2

A common trouble is this :

#define DIV(a,b) a / b

printf("25 / (3+2) = %d", DIV(25,3+2));

It will print 10, not 5, because the preprocessor will expand it this way:

printf("25 / (3+2) = %d", 25 / 3 + 2);

This version is safer:

#define DIV(a,b) (a) / (b)

Answer 3

Macros are valuable especially for creating generic code (macro's parameters can be anything), sometimes with parameters.

More, this code is placed (ie. inserted) at the point of the macro is used.

OTOH, similar results may be achived with:

• overloaded functions (different parameter types)

• templates, in C++ (generic parameter types and values)

• inline functions (place code where they are called, instead of jumping to a single-point definition -- however, this is rather a recommandation for the compiler).

edit: as for why the macro are bad:

1) no type-checking of the arguments (they have no type), so can be easily misused 2) sometimes expand into very complex code, that can be difficult to identify and understand in the preprocessed file 3) it is easy to make error-prone code in macros, such like:

#define MULTIPLY(a,b) a*b

and then call

MULTIPLY(2+3,4+5)

that expands in

2+3*4+5 (and not into: (2+3)*(4+5)).

To have the latter, you should define:

#define MULTIPLY(a,b) ((a)*(b))

Answer 4

I don't think that there is anything wrong with using preprocessor definitions or macros as you call them.

They are a (meta) language concept found in c/c++ and like any other tool they can make your life easier if you know what you're doing. The trouble with macros is that they are processed before your c/c++ code and generate new code that can be faulty and cause compiler errors which are all but obvious. On the bright side they can help you keep your code clean and save you a lot of typing if used properly, so it comes down to personal preference.

Answer 5

Macros in C/C++ can serve as an important tool for version control. Same code can be delivered to two clients with a minor configuration of Macros. I use things like

#define IBM_AS_CLIENT
#ifdef IBM_AS_CLIENT 
  #define SOME_VALUE1 X
  #define SOME_VALUE2 Y
#else
  #define SOME_VALUE1 P
  #define SOME_VALUE2 Q
#endif

This kind of functionality is not so easily possible without macros. Macros are actually a great Software Configuration Management Tool and not just a way to create shortcuts for reuse of code. Defining functions for the purpose of reusability in macros can definitely create problems.

Answer 6

Preprocessor macros are not evil when they are used for intended purposes like:

• Creating different releases of the same software using #ifdef type of constructs, for example the release of windows for different regions.
• For defining code testing related values.

Alternatives- One can use some sort of configuration files in ini,xml,json format for similar purposes. But using them will have run time effects on code which a preprocessor macro can avoid.

Answer 7

In my experience macros are not ideal for program size and can be difficult to debug. But if used carefully they are fine.

Often a good alternatives are generic functions and/or inline functions.