The preprocessor in either C or C++ is evil for the simple matter you can't debug it when the thing you're debugging is in production, symbols are stripped, and the disassemble resembles nothing you can marry up to actual C or C++ code. In simple cases, maybe, but in not so simple cases it's just evil.
A modern compiler will optimized out the global consts anyways too...
If you have a modern toolchain stack unwinding is already friendly to macro expansion.
A production build does not mean you don't have symbols, it just means you don't have symbols in the executable. Stash your build symbols somewhere so you can symbolize the stacks offline. Macros don't change this. They are consistent output for the same input.
Macros are not evil. Abusable, yes, but they also solve various sets of problems just better than any other solution.
macro expansion is useless, again, for same reason you can't marry it to actual code. If you can do this now, would be at most curious (not interested) as it's evil to begin with.
A production build in the embedded world, typically means you don't have symbols. Often they are stripped to save space and unless you have a USB stick or something you carry with you with map files, you're still toast.
And there are a whole host of other reasons why they are just pure evil:
1. Global scope only. 2. Unexpected results rather than error messages - ISO25259 won't even allow you to do this if that tells you anything. 3. Can't use sizeof 4. no type checking. Every compiler I've used, including GCC, won't warn about if an int is compared to unsigned. 5. can't take the address 6. worst, substituted value need not even be legal in the context the #define is created because it is evaluated at each point it is referenced allowing to another evil problem of being able to reference objects that are not declared yet.
I could go no... and I haven't even touched on strings yet.
with so many problems, I have a hard time justifying or championing their use.
So are functions, by that rationale. If you want to control scope of variables, pass in macro parameters.
> 2. Unexpected results rather than error messages
When have min() or max() produced unexpected results rather than error messages? They're macros, you know.
> Every compiler I've used, including GCC, won't warn about if an int is compared to unsigned.
-Wconversion
> 5. can't take the address
You can't take the address of a struct definition or a typedef, either. Macros are not replacements for functions; they're code generators.
> 6. worst, substituted value need not even be legal in the context the #define is created because it is evaluated at each point it is referenced allowing to another evil problem of being able to reference objects that are not declared yet.
I don't even... You do know that, following the preprocessing phase, the compiler actually checks the generated code for legality, right? And since when is forward referencing evil?
#define a_ frob(-1,0,0); grob("a"); blah(...);
#define b_ frob(1,0,0); grob("b"); blah(...);
#define c_ frob(0,-1,0); grob("c"); blah(...);
#define d_ frob(0,-1,1); grob("d"); blah(...);
#define e_ frob(0,0,-1); grob("e"); blah(...);
#define f_ frob(0,1,1); grob("f"); blah(...);
if (normal_order) {
a_ b_ c_ d_ e_ f_;
c_ b_ a_ f_ e_ d_;
} else if (special_order_1) {
b_ c_ d_ e_ a_;
d_ e_ c_ b_ a_ f_;
} else if (...) {
// ... and so on ...
}
#undef a_
#undef b_
#undef c_
#undef d_
#undef e_
#undef f_ auto a = [] {frob(-1,0,0); grob("a"); blah(...);};
auto b = [] {frob(1,0,0); grob("b"); blah(...);};
auto c = [] {frob(0,-1,0); grob("c"); blah(...);};
...
if (normal_order) {
a(); b(); c(); ...
} else if (...) {
b(); c(); a(); ...
} ... #define LIST_ERROR_TYPES(X) \
X(OK, "") \
X(ERR_OOM, "out of memory") \
X(ERR_BAD_STRING_ENCODING, "string was invalid utf-8") \
...
#define DEF_ENUM(ident,_) ident,
typedef enum { LIST_ERROR_TYPES(DEF_ENUM) } err_t;
const char *get_err_msg(err_t err) {
#define IDENT2MSG(ident,msg) case ident: return msg;
switch (err) {
LIST_ERROR_TYPES(IDENT2MSG)
default: return "unknown error";
}
}
If you want to see some actual code, I use X-macros, as well as other macros, heavily in the test suite for my (very) WIP programming language: https://github.com/alpha123/yu/tree/master/test
There's some other interesting and generic macros that I frequently use in there too: https://github.com/alpha123/yu/blob/master/src/yu_common.h
#define DISALLOW_COPY_AND_ASSIGN(TypeName) \
TypeName(const TypeName&) = delete; \
void operator=(const TypeName&) = delete
Modern C++ did not replace macros nor did it even try. some uses of macros were made obsolete (like min/max), but most were not.
I've always found macros pretty horrid for debugging because you can't step through them properly. I just tried with gcc 6.0 and gdb 7.11 and it still seems to be unsupported, 20-odd years after the first time I rued the lack of this functionality. At this rate I strongly suspect this will never, ever work. (Another black mark against macros that expand to anything significant, in my view.)
If you want to step through execution of a function defined by a macro, preprocess with -E -P and compile that. For more advanced (and pleasant) macro debugging, you can do a little trick:
1. Create an e.g. include/dummy directory and create empty versions of whatever headers you don't want to expand.
2. Run your files through $CC -E -P -Iinclude/dummy
3. clang-format is your friend for making the output much nicer.
4. Compile with explicit -include of the real versions of files in include/dummy.
5. Debug normally.
It takes a little bit of effort to get right, but after that you can just throw it in a Makefile and forget about it (e.g. https://github.com/alpha123/yu/blob/master/Makefile#L96-L126).
On top of it all, they require constant(!) connection to license server and will throw annoying popups if being disconnected for few minutes. It's so frustrating to constantly being punished by DRM even if I'm paying customer.
Sorry for rant, I just needed to vent a bit.
And yeah, I hated using it too. Awful stuff. We went to great lengths to allow a testing version of the firmware to be built using Visual C++ and executed locally, just so we could avoid using the Green Hills stuff whenever possible.