Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Struct Iteration Through Abuse of the C Preprocessor

natecraun.net

Post reply on HN
Print view View original

11–20 of 27 posts

Re: Struct Iteration Through Abuse of the C Preprocessor

#11

Post by Kristine1975 »

uxcn wrote: post #8
ncraun wrote: post #6

Earlier quoted context omitted.

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!

It can be a bit tricky if it isn't integrated with the build process.

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

#12

Post by Kristine1975 »

kevingadd wrote: post #2

You can do some interesting things using __COUNTER__ to make code using this less ugly. And if you're willing to use a small amount of C++ templates, you can make it possible to resolve all the iteration/member info at compile time to eliminate runtime overhead. I did both of these things for Grim Fandango for vertex/uniform buffers, so that the game could use buffers without caring about whether it was using OpenGL…

I'm doing something similar in C++ for vertex attributes, integration with Lua et.al. First I define the struct:

  INTROSPECTION_DEFINE_STRUCT(S,
    (int, anInt),
    (bool, aBool),
    (float, aFloat),
    (double, aDouble),
    (std::string, aString)
  );
Then I create an instance of it:

  S s{ 23, true, 37.5f, 42.25, "String" };
And finally I can e.g. iterate over all fields and output their value using a generic lambda:

  forEachField(s, [](auto v) {
    std::cout
There are also definitions for the field's type, offset, name etc. generated by the macro, so it's easy to create a binding for vertex attributes, map the struct to a table in Lua, serialize/deserialize it and so on.

I'm really hoping C++ gets introspection soon. There are some proposals like https://isocpp.org/files/papers/n3996.pdf and a working group at https://groups.google.com/a/isocpp.org/forum/#!forum/reflect... but I'm not holding my breath for 2017.

Re: Struct Iteration Through Abuse of the C Preprocessor

#14

Post by DannyBee »

anon4 wrote: post #5
evmar wrote: post #4

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?

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 r…

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

#15

Post by uxcn »

Kristine1975 wrote: post #11
uxcn wrote: post #8

Earlier quoted context omitted.

It can be a bit tricky if it isn't integrated with the build process.

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.

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

#16

Post by dman »

Kristine1975 wrote: post #12
kevingadd wrote: post #2

You can do some interesting things using __COUNTER__ to make code using this less ugly. And if you're willing to use a small amount of C++ templates, you can make it possible to resolve all the iteration/member info at compile time to eliminate runtime overhead. I did both of these things for Grim Fandango for vertex/uniform buffers, so that the game could use buffers without caring about whether it was using OpenGL…

I'm doing something similar in C++ for vertex attributes, integration with Lua et.al. First I define the struct: INTROSPECTION_DEFINE_STRUCT(S, (int, anInt), (bool, aBool), (float, aFloat), (double, aDouble), (std::string, aString) ); Then I create an instance of it: S s{ 23, true, 37.5f, 42.25, "String" }; And finally I can e.g. iterate over all fields and output their value using a generic lambda: forEachField(s, […

Is the code for this available somewhere?

Re: Struct Iteration Through Abuse of the C Preprocessor

#17

Post by cperciva »

kevingadd wrote: post #2

You can do some interesting things using __COUNTER__ to make code using this less ugly. And if you're willing to use a small amount of C++ templates, you can make it possible to resolve all the iteration/member info at compile time to eliminate runtime overhead. I did both of these things for Grim Fandango for vertex/uniform buffers, so that the game could use buffers without caring about whether it was using OpenGL…

__COUNTER__ isn't portable (yet).

Re: Struct Iteration Through Abuse of the C Preprocessor

#18

Post by comex »

DannyBee wrote: post #14
anon4 wrote: post #5

Earlier quoted context omitted.

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 r…

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.

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.

Re: Struct Iteration Through Abuse of the C Preprocessor

#19

Post by comex »

A bit cleaner setup, in my opinion, makes the "x macro" an argument to the user-defined macro, rather than depending on #include. For example, to define an enum along with a string representation function for it:

    #define DEFINE_ENUM(name, variants) \
      enum name { \
        variants(DEFINE_ENUM_VARIANT_ITSELF) \
      }; \
      const char *repr_##name(enum name e) { \
        switch (e) { \
          variants(DEFINE_ENUM_VARIANT_REPR_CASE) \
          default: return "?"; \
        } \
      }
    #define DEFINE_ENUM_VARIANT_ITSELF(variant) variant,
    #define DEFINE_ENUM_VARIANT_REPR_CASE(variant) \
      case variant: return #variant;

    // client code:

    #define foo_variants(x) \
      x(FOO_1) \
      x(FOO_2)
    DEFINE_ENUM(foo, foo_variants)
Post reply on HN