Fun with C++: Macro Pitfalls, Batch 1!
(UPDATE: Added the 6th item.)
I’m a fan of C/C++ preprocessor macros. I would be very happy if C++ received macros on par in power with those of Common Lisp macros, but that’s only a dream! We have to work with what we have.
Anyways, with use of macros come a lot of potential pitfalls. I’m going to go over a couple of them. I’m sure any C++ programmer is aware of these, but the reiteration would hurt now, would it? I’m also hoping that with your feedback, we can complete these into something referable and usable.
- Operator Mishaps From Hell!
This is a classic example.#define SQR(x) x * xImagine what happens when you use something like SQR(a + b). But as I said, this is a classic example, and any C programmer with half a brain should know enough to avoid this (doesn’t mean it always happens though. We all have our shameful secrets!)
The moral is: always enclose every usage of macro parameters in parentheses as well as the whole thing. (#define SQR(x) ((x) * (x))) - The Space From Hell!
#define SQR (x) ((x) * (x))Notice the space between SQR and the (x)? The programmer didn’t! It usually results in a cryptic compile error about something not being a function or about incorrect number of arguments. Easy for more experienced programmers to understand and rectify (usually with a bang to their heads.)
Also, it’s not hard to imagine cases without any compile errors and severe oddities in runtime behavior. Remember: Compile-time errors and warnings are your friends as long as you pay attention to them! They might be a little hard to understand, but a project with 100 pain-in-the-neck compile errors is better than 100 hidden runtime bugs just waiting to cut your neck off. - The Semicolon From Hell!
Let me demonstrate the perils of the semicolon.// A macro to increment a counter, and wrap around to zero is a limit is reached. #define ADVANCE(x, wrap) ((x) = ((x)+1)%(wrap)); // Usage 1 while (should_go_on) ADVANCE(i, 100); // Usage 2 for ( ; should_go_on; ADVANCE(i, 100)) {} // Usage 3 while (should_go_on) p = ADVANCE(i, 100) + 100;
As long as you stick to the first usage (i.e. as a statement,) you get away with your mistake (the spurious semicolon at the end of the macro definition.) However, usage 2 won’t compile. But this is a good thing, since you will know that you have an error in your macro (of course, if you’re a newbie in C++, it may take you quite a few minutes to figure this one out.)
Usage 3 is where things get interesting. The code will compile (at most with a mysterious and seemingly unrelated warning,) but it won’t do what you think it does. That can be a bitch to track down.
So, the moral of this story is: don’t put semicolons in macros! - The Multiple Evaluations From Hell!
#define SQR(x) ((x) * (x))What happens when you evaluate the value of SQR(++a)? Does that seem alright to you? (By the way, any one who tells you a += b is equivalent with a = a + b is either a moron, or thinks you are a moron!)
The lesson of this item is: don’t use macros as fast, generic functions! Use inline templates (which are even potentially faster (do you know when?
)) Like this:template <typename T> inline const T & sqr (const T & x) {return x * x;}
- The Multiple Statements From Hell!
The following macro deletes a pointer and sets it to 0, a very sensible thing to do nearly all the time.// This is not OK. Don't use this macro like this. Keep reading down this article! // Also note that I've not placed a semicolon at the end. #define SAFE_DELETE(ptr) delete (x); (x) = 0 // Usage 1 char * s = new char [42 + 1]; ... SAFE_DELETE(s); // Usage 2 if (some_condition) SAFE_DELETE(s);
But it doesn’t work, does it? I mean, usage 1 is OK, but you’ll wish you were never born when you have to stay up late into the night and debug the results of the second usage, won’t you? So, what do we do? I imagine everybody’s first response would be:
// This is not OK, still. #define SAFE_DELETE(ptr) {delete (x); (x) = 0;} // Usage 3 if (some_condition) SAFE_DELETE(s); else doSomeWork (s);
See the problem? No? The problem is in the semicolon before else. C++ doesn’t let you put a semicolon after an closing curly brace (’}') and before “else”. So what do we do? This is one of the solutions:
// This is almost OK, and usable if you are not very picky. #define SAFE_DELETE(ptr) do { delete (x); (x) = 0; } while (false)
That’s right! We put the multiple statements inside a do/while block that is guaranteed to be executed only once! Brilliant, isn’t it? Well, I didn’t come up with it. I wish I could say that I though of it independently, but that’s not the case. I saw it in kernel code even before I had run into this problem! But the code didn’t say why it was used this way, and analyzing and discovering the purpose of this small piece of code was one of my biggest “Aha!” moments in C programming.
So, we are good to go, right? Well, not quite. If you don’t care much about warnings the compiler gives off, you are good to go. But the above code results in a warning (only when you have turned the compiler warning level to the highest degree,) that the used condition is constant. Although the occasions for this warning are intentional most of the time (like here,) it may be the case that the compiler is warning us about a typo. Because of this, I don’t want to disable this warning (unlike those blasted 4996 warnings Visual C++ gives off like candy on Halloween, which I shut off with a wide and hysterical grin, while caressing my ax handle!)
So what do we do? The best solution that occurs to me is like this:// We define a function that always returns false namespace __useless { inline bool i_am_false () {return false;} } // Now we use the above function instead of hard-coding the constant expression #define SAFE_DELETE(ptr) do { delete (x); (x) = 0; } while (__useless::i_am_false())
We trick the compiler here. The compiler is wise enough (or not smart enough) to give a warning no more, but any optimizer would optimize the overhead of the function call away completely.
- The “if” From Hell!
Suppose we “optimize” the above SAFE_DELETE macro, to check whether the argument is NULL, and do nothing in that case.#define SAFE_DELETE(ptr) if(ptr) delete (ptr), ((ptr) = 0) // Note that I've incorporated the comments from Hadi (comment 2) here, to make a point. // Usage 1 if (some_condition) SAFE_DELETE (s); else return 0;
Ouch! That hurts. I don’t think there’s anyone who doesn’t know this already, but in case there is (almost no shame in not knowing,) the “else” in the first usage will be the else clause for the “if” inside the macro! You are going to hate Dennis Ritchie after the first two hours of bewilderment over this (but of course, that would be out of frustration, and without logical cause!)
You may be tempted to solve the problem like this:#define SAFE_DELETE(ptr) if(ptr) {delete (ptr); (ptr) = 0;} else {}But don’t! Do this:
#define SAFE_DELETE(ptr) do { if(ptr) {delete (ptr); (ptr) = 0;} } while (__uselss::i_am_false())The moral? If you write “if” clauses in macros, be extra careful.
The above were only some of the pitfalls, but I can’t continue right now. Looking forward to your suggestions. Don’t be shy!
