> The c preprocessor replaces something by something else and the process is completely opaque. If you have multiple layers of macros, codes becomes impossible

> 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. It's not true for Datatype99 & Interface99. Their code generation semantics are completely transparent to a user of these macros [1] [2]. > 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. If you use third-party tools and you're okay with that, I'm not saying you should stop using them, I'm saying that there is another solution with advantages over third-party tools [3]. If native macros haven't worked for your codebase, it doesn't mean they don't work for others. I would not say that the preprocessor is a thing to always avoid -- there are many examples why it is helpful, and even more helpful than any kind of third-party tools you can come up with. > 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. How third-party tools are different from native macros in this case? [1]: https://github.com/Hirrolot/datatype99#semantics https://github.com/Hirrolot/datatype99#semantics [2]: https://github.com/Hirrolot/interface99#semantics https://github.com/Hirrolot/interface99#semantics [3]: https://github.com/Hirrolot/metalang99#q-why-not-third-party-code-generators https://github.com/Hirrolot/metalang99#q-why-not-third-party...