Hacker News new | past | comments | ask | show | jobs | submit login

If you want a dense, readable, maintainable code - you're out of options, you have to resort to the preprocessor.

Any kind of repeating lists (enum + a switch over all the values, for example) are best handled by define-include-undefine sequences.

See how it is done in LLVM, see all the .def files there. I cannot think of a single viable alternative to this method.

And it is far from a "code generation", just merely listing things in a consistent manner.




> Any kind of repeating lists (enum + a switch over all the values, for example) are best handled by define-include-undefine sequences.

> See how it is done in LLVM, see all the .def files there. I cannot think of a single viable alternative to this method.

I've seen x-macros. I'm not sure I've seen them used to good effect, but I'd definitely be curious how the llvm code uses them.

> If you want a dense, readable, maintainable code - you're out of options, you have to resort to the preprocessor.

I guess it wasn't entirely obvious from my comment, but I wasn't arguing against using the preprocessor. It's self-contained, mostly usable with common tools, etc.. Anything that's supported on more than one platform or has compile time options generally depends on it. Dense, readable, maintainable code is definitely a good thing, which is one of the reasons I'd personally like to see a usable reflection land in C++.


> which is one of the reasons I'd personally like to see a usable reflection land in C++.

Of course. Reflection and proper macros. At least something like mbeddr would have been great.

I never said preprocessor is the best possible option. I'm only saying that at the moment it is the only practically available option, and therefore it's unavoidable, like it or not. I personally hate it with a passion, but I have to use it extensively.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: