> If my macros produce standards-compliant code and they make my code easier to read and understand, why shouldn't I use them?
The problem is they don't make code easier to read and understand. Worse, the unhygienic nature of C macros makes it hard to contain them.
I haven't seen your code, so I'm speaking based on what I've seen of mine and others' code. If you dial it back, the person who has to deal with your code after you leave will appreciate it.
More generally speaking, if you're doing metaprogramming with the C macro system, you've outgrown the language and should consider a more powerful one.
I once worked at a place that had a platform specific "DEBUG" log macro.
It worked something like: DEBUG(msg); Except, it was defined in such a way that you actually had to have two closing parens, like DEBUG(msg)); It looked syntactically invalid, but whatever the macro did required it.
The entire code base was littered with WTFs like that...
I hated debug macros. There just was never a clean way to write them. I was determined that D would not suffer from that problem. `debug` is a keyword in D, and you can do things like:
debug printf("I got here\n");
and the printf only gets compiled in when compiling with -debug. (Any statement can be used after the printf.) Even better, semantic checks for debug statements are relaxed - for example, purity is not checked for them.
Meaning you can embed debug printf's in functions marked 'pure', instead of having to use a monad.
The problem is they don't make code easier to read and understand. Worse, the unhygienic nature of C macros makes it hard to contain them.
I haven't seen your code, so I'm speaking based on what I've seen of mine and others' code. If you dial it back, the person who has to deal with your code after you leave will appreciate it.
More generally speaking, if you're doing metaprogramming with the C macro system, you've outgrown the language and should consider a more powerful one.