Re:Struct Iteration Through Abuse of the C Preprocessor
by evmar on Tuesday October 13, 2015 @11:26AM
(#10381080)
Taking a step back: what you're trying to accomplish is code generation -- a program that generates code. From that perspective, why would you choose to write that program using the C preprocessor, when there are so many other nice languages around?
[ Parent
| on HN ]
Re:Struct Iteration Through Abuse of the C Preprocessor
by ncraun on Tuesday October 13, 2015 @11:57AM
(#10381289)
In actual production use, I think it could be better to write a separate program that will generate the code for you instead of using the C preprocessor (or use a language with this kind of introspection built in). However, using this hack lets you depend only on the facilities of the language, and that can be useful in simplifying the build process. Plus it was fun to create, too!
Re:Struct Iteration Through Abuse of the C Preprocessor
by uxcn on Tuesday October 13, 2015 @12:20PM
(#10381479)
It can be a bit tricky if it isn't integrated with the build process.
Re:Struct Iteration Through Abuse of the C Preprocessor
by Kristine1975 on Tuesday October 13, 2015 @01:40PM
(#10382066)
You can use e.g. cog which puts the generated code into the file itself: http://nedbatchelder.com/code/cog/
Then all you need to do is to remember to run the preprocessor after you've made a change to the generator code.
Re:Struct Iteration Through Abuse of the C Preprocessor
by uxcn on Tuesday October 13, 2015 @03:01PM
(#10382677)
Python is definitely a better syntax to write meta-programs than the pre-processor, but you still have the issue of the additional step/tool. Anything that depends on the generated code depends on the step which, if it's missed, can lead to non-good things.
Re:Struct Iteration Through Abuse of the C Preprocessor
by Kristine1975 on Wednesday October 14, 2015 @02:50AM
(#10385326)
Sure. But you do test your changes, don't you? ;-) So if you forget to run cog after making a change to the meta-program, you should notice right away.
But it still is a cludge. It would be better if C/C++ had a better preprocessor.
Re:Struct Iteration Through Abuse of the C Preprocessor
by uxcn on Wednesday October 14, 2015 @11:22AM
(#10387110)
It isn't a question of testing changes. The more people working on the codebase, the more people it impacts. Adding manual steps is tempting the fates.
Re:Struct Iteration Through Abuse of the C Preprocessor
by anon4 on Tuesday October 13, 2015 @11:39AM
(#10381171)
This is what I was going to suggest. C is even pretty easy to parse - you can just take the ready ANTLR grammar and use it to generate a parser in whatever language you want.
Of course, he might go even one step further and specify the structs in some other language, then generate C source files from them, which would also allow you to easily generate consumers for that data format in other languages and now you're reinventing Cap'n Proto.
Re:Struct Iteration Through Abuse of the C Preprocessor
by DannyBee on Tuesday October 13, 2015 @02:38PM
(#10382509)
Errr, he doesn't even need to use ANTLR, he can use clang, as a library. It can be linked into an app, has a nice AST, and matching abilities:
http://clang.llvm.org/docs/LibASTMatchersReference.html
Now he has the actual compiler doing the work for him.
Re:Struct Iteration Through Abuse of the C Preprocessor
by comex on Tuesday October 13, 2015 @04:24PM
(#10383215)
Sure, and now everyone who wants to compile your program has to install clang, which might take forever to compile for someone on a source-based distro, or require PITA manual work such as on Windows. Not to mention that you have to figure out how to configure your build system to (a) depend on clang and (b) build a helper program (including overriding the normal target architecture choice) - the difficulty of which depends on your setup, but if you follow the common practice of maintaining separate Visual Studio and CMake/etc. project files, in order to cater to IDE users while still being cross-platform, you have to do it twice!
I hate build systems.