C Preprocessor Hell

I don't know why people don't seem to think of this when confronted with the limitations of the standard C preprocessor, but Perl or Lisp both make excellent C preprocessors.<p>You aren't required to only use the C source code transformation tools that a default install of GCC provides.

The code in the article is actually less horrible than I expected from the title. However, it seems like a situation which could be more elegantly solved with X-Macros (<a href="http://drdobbs.com/cpp/184401387" rel="nofollow">http://drdobbs.com/cpp/184401387</a>), provided that you consider X-Macros elegant.<p><i>X-Macros: you have a header file consisting of lines in the form of "FOO(name, type, defvalue);" and include it several times with different definitions for FOO.</i>

Why not just make an internal API function? In my experience with high performance, multiplatform C, macro usage is usually the last thing we do. Macros are absolutely horrendous to debug, and tends to lead to less readable code. They're useful to alias specific platform implementations to a standard interface, or for tiny functions that absolutely need to be inlined for performance.<p>In this specific case, it might make more sense to have the programmer tell you how many arguments to expect and work with it that way, rather than going through this chain of macros. C doesn't allow function arguments to change dynamically, so that might be a slightly better approach. It would be easier to understand, but a bit harder to maintain code that uses it.

The ## in front of __VA_ARGS__ is a gcc extension.

"Lisp programmers should stop reading right now because they'll likely suffer severe injury of the jaw muscles as they laugh themselves silly at how hard it is to do some things in C."<p>Naive question: in Lisp, how would you set the byte at address 0xDEADBEEF to 0x42?