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?
Best Answer
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):
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, you can't "see" what the macro translates to. So you don't actually know what is going on.
Replacement: Use
enum
orconst 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 usex2 = SQUARE(x++)
. That leads tox2 = (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:
and then
It actually becomes completely the wrong thing....
Replacement: real functions.
3) Macros have no namespace
If we have a macro:
and we have some code in C++ that uses begin:
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:
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:
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 updatex
twice, which is undefined and will probably lead to different values on different systems, and different outcome value inx
as well.