Why are preprocessor macros evil and what are the alternatives?
Solution 1:
Macros are just like any other tool - a hammer used in a murder is not evil because it's a hammer. It is evil in the way the person uses it in that way. If you want to hammer in nails, a hammer is a perfect tool.
There are a few aspects to macros that make them "bad" (I'll expand on each later, and suggest alternatives):
- You can not debug macros.
- Macro expansion can lead to strange side effects.
- Macros have no "namespace", so if you have a macro that clashes with a name used elsewhere, you get macro replacements where you didn't want it, and this usually leads to strange error messages.
- Macros may affect things you don't realize.
So let's expand a little here:
1) Macros can't be debugged. When you have a macro that translates to a number or a string, the source code will have the macro name, and many debuggers can't "see" what the macro translates to. So you don't actually know what is going on.
Replacement: Use enum or const T
For "function-like" macros, because the debugger works on a "per source line where you are" level, your macro will act like a single statement, no matter if it's one statement or a hundred. Makes it hard to figure out what is going on.
Replacement: Use functions - inline if it needs to be "fast" (but beware that too much inline is not a good thing)
2) Macro expansions can have strange side effects.
The famous one is #define SQUARE(x) ((x) * (x)) and the use x2 = SQUARE(x++). That leads to x2 = (x++) * (x++);, which, even if it was valid code [1], would almost certainly not be what the programmer wanted. If it was a function, it would be fine to do x++, and x would only increment once.
Another example is "if else" in macros, say we have this:
#define safe_divide(res, x, y) if (y != 0) res = x/y;
and then
if (something) safe_divide(b, a, x);
else printf("Something is not set...");
It actually becomes completely the wrong thing....
Replacement: real functions.
3) Macros have no namespace
If we have a macro:
#define begin() x = 0
and we have some code in C++ that uses begin:
std::vector<int> v;
... stuff is loaded into v ...
for (std::vector<int>::iterator it = myvector.begin() ; it != myvector.end(); ++it)
std::cout << ' ' << *it;
Now, what error message do you think you get, and where do you look for an error [assuming you have completely forgotten - or didn't even know about - the begin macro that lives in some header file that someone else wrote? [and even more fun if you included that macro before the include - you'd be drowning in strange errors that makes absolutely no sense when you look at the code itself.
Replacement: Well there isn't so much as a replacement as a "rule" - only use uppercase names for macros, and never use all uppercase names for other things.
4) Macros have effects you don't realize
Take this function:
#define begin() x = 0
#define end() x = 17
... a few thousand lines of stuff here ...
void dostuff()
{
int x = 7;
begin();
... more code using x ...
printf("x=%d\n", x);
end();
}
Now, without looking at the macro, you would think that begin is a function, which shouldn't affect x.
This sort of thing, and I've seen much more complex examples, can REALLY mess up your day!
Replacement: Either don't use a macro to set x, or pass x in as an argument.
There are times when using macros is definitely beneficial. One example is to wrap a function with macros to pass on file/line information:
#define malloc(x) my_debug_malloc(x, __FILE__, __LINE__)
#define free(x) my_debug_free(x, __FILE__, __LINE__)
Now we can use my_debug_malloc as the regular malloc in the code, but it has extra arguments, so when it comes to the end and we scan the "which memory elements hasn't been freed", we can print where the allocation was made so the programmer can track down the leak.
[1] It is undefined behaviour to update one variable more than once "in a sequence point". A sequence point is not exactly the same as a statement, but for most intents and purposes, that's what we should consider it as. So doing x++ * x++ will update x twice, which is undefined and will probably lead to different values on different systems, and different outcome value in x as well.
Solution 2:
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).
Solution 3:
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)
Solution 4:
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))