Reflect an existing enum?

[no-more-secrets]

Does this library have a macro for reflecting an existing enum class (which is not reflected in any way)? I understand that this would require restating the enum values, but that's ok. Essentially, this would be for a case where we need to reflect an enum but cannot change the original declaration.

[aantron]

No, not at the moment. You can define a new reflective enum with

BETTER_ENUM(Foo, int, A = OtherEnum::A, B = OtherEnum::B)

and use this second enum for conversions of values of OtherEnum.

[no-more-secrets]

Ok, thanks; any plans to add this feature? :-) Perhaps you could reuse essentially the same large macro to define it, but instead of creating an actual enum inside of it, you can just instead have a using directive to point to the original one, so instead of:

#define BETTER_ENUMS_ENUM_CLASS_SWITCH_TYPE_GENERATE(Underlying, ...)          \
    enum class _enumClassForSwitchStatements : Underlying { __VA_ARGS__ };

you could have:

#define BETTER_ENUMS_ENUM_CLASS_SWITCH_TYPE_GENERATE(Existing, ...)          \
    using _enumClassForSwitchStatements = Existing;

But of course I could be wrong since I am not too familiar with this code,
Thanks

[aantron]

It's feasible at first glance, but I wouldn't have time in the near future to do this, test it everywhere, etc. If you would like to give it a try, I would be happy to merge the PR. If you make something like this locally, but don't want to test it on all the systems and configurations and whatnot, I'd also be very happy if you opened a PR with your approach. We would close and not merge it, but it would give us a nice starting point if I/someone else wanted to finish it "all the way" later :)

[no-more-secrets]

Ok, I will take a look and try to put together a PR. For testing I will follow the directions in CONTRIBUTING.md (assuming it is up to date). Thanks

[prcxx]

Does this library have a macro for reflecting an existing enum class (which is not reflected in any way)? I understand that this would require restating the enum values, but that's ok. Essentially, this would be for a case where we need to reflect an enum but cannot change the original declaration.

To have reflecting an existing enum you can use https://github.com/Neargye/magic_enum for example.

[aantron]

I linked magic_enum from the README. It looks like it requires GCC 9, but otherwise, is likely to be a better solution for many situations. If so, I'd like to gradually deprecate Better Enums. cc @Neargye

[Neargye]

Hi @aantron,

Both libraries solve similar problems, but with a different implementation.

Difference:

Better Enums

• Need registered enum (by macro).
• C++98/11.

Magic Enums

• No need registered enum.
• C++17. It is possible in theory to reduce the version to С++14, but need to write own implementations optional and string_view.
• GCC>=9. Only since this gcc version support intrinsics PRETTY_FUNCTION to get enum name.
• There may be a problem with large enums if there are more than 512 elements in it. Not the most usual case, but it is worth remembering this.

[no-more-secrets]

Cool! I will give magic_enum a try; I suppose that it might be able to replace most uses of Better Enums in my code. But of course it is not the right solution for everyone due to the requirements on compilers and compiler versions (i.e., parsing PRETTY_FUNCTION is compiler specific).

[Neargye]

@dpacbach Unfortunately, "magic" depends on the compiler :D

[aantron]

@Neargye thanks. "Perversely," on MSVC, magic_enum might actually have less of a limit than Better Enums. Better Enums uses macro expansion, which is (or was?) limited to 127 arguments on MSVC.

I think the main genuine advantage of Better Enums is that it can easily handle large sparse ranges, and constants with arbitrary values, whereas magic_enum seems to "like" dense, contiguous, narrow ranges. Most enums fall into that latter category, though, so magic_enum is probably the better solution for most uses. This should become more and more true as GCC 9 becomes more common, and future versions are released.

[aantron]

Well, and that Better Enums uses standard C++. But I think the vast majority of users are on GCC, Clang, or MSVC, so this is not a big deal.