[spacechild1]

The downside is, of course, that it's ugly and very awkward to use.

That's the essence of C++: you're basically trading ergonomics for compile times.

[uecker]

Are X macros awkward? I find them very straightforward and clear.

[spacechild1]

The implementation doesn't look too bad, but the usage is terrible:

  #define E_LIST(X) \
      X(V0) X(V1) X(V2) X(V3)

  DEFINE_ENUM(E, E_LIST)

That's not how I want to declare my enums...

[SuperV1234]

To be honest there are ways to make that much nicer. I believe that if you use recursive macros using the VA_OPT feature, you should be able to provide enumerators directly to define enum as a list.

The underlying machinery implementation is going to be much uglier and complex, though.

See https://www.scs.stanford.edu/~dm/blog/va-opt.html

[spacechild1]

Oh, I didn't know about __VA_OPT__(), thanks for that!

That looks much nicer indeed, but I still vastly prefer the other solutions, simply because I can just declare regular enums.

[uecker]

In practice it is written like like this:

  #define MY_ENUM(x) x(MY_A) x(MY_B) x(MY_C)
  enum my_enum { MY_ENUM(ENUM_ENTRIES) };

  static const char *my_enum_names[] = { MY_ENUM(ENUM_NAMES) };

but one could also make it even more compact if one cared.

[spacechild1]

That doesn't look any better.

Yes, xmacros have the best compile times, but you can't possibly argue that they are elegant to use compared to the alternatives.

[uecker]

It looks better to me than the other macro solution as it is more transparent what is done compared to DEFINE_ENUM. But I agree it is not as succinct as C++'s reflection syntax.

[spacechild1]

> It looks better to me than the other macro solution as it is more transparent what is done compared to DEFINE_ENUM.

Fair enough.

[psyclobe]

They are gross but... effective so shrug