>Have you ever envisioned the daily C preprocessor as a tool for some decent metaprogramming?
Never had such a nightmare.
For metaprogramming C you should use real macros like Lisp. We have been doing that for a long time.
Using the C preprocesor is a terrible idea. With the preprocessor you could create code, but a professional environment requires things like being able to go backwards, not just from Macro source code to executable but from the executable to source code.
What do I mean with that?
In a professional environment, when something happens, for example your program goes too slow for a customer you need to understand what is happening as fast as possible. C MACROS and preprocessor are evil for that.
The c preprocessor replaces something by something else and the process is completely opaque. If you have multiple layers of macros, codes becomes impossible to follow, isolate and understand with a debugger or a profiler.
All our code has C MACROS of any type forbidden, only permitted in external libraries. Our build process detects C Macros and stops compilation if it finds them.
Usually the way things work someone creates a easy C macro to automate some small thing, then a month later someone else creates another macro that uses the macro in a two layer system, then someone else creates another macro over the macros and leaves the old macros there.
That makes code extremely hard to understand, isolate, modularize, trace or debug. C programmers could have the temptation not to learn different tools for metaprogramming. We don't let you do that, if you want to do metaprogramming you are forced to learn the proper tools for the job.
That has made our codebase extremely robust. We use real metaprogramming with our own tools, not hacks, and that gives us a tremendous competitive advantage because problems takes 1/10th or 1/100th the time for being solved.