enum_traits VS Better Enums

On the topic of this kind of hackflection willwray/enum_traits uses an interesting trick where they improve buildtime performance by doing the __PRETTY_FUNCTION__/__FUNCSIG__/std::source_location::current().function_name() inside a variadic templated function to do the name conversion for a batch of integers at the same time to make it less expensive (compiletime) to test a large range of numbers.

You could try https://github.com/willwray/enum_traits. Check out the demo repo https://github.com/willwray/enum_reflect

I really like better_enums instead of magic_enums. There’s no limit on enum size with it: http://aantron.github.io/better-enums/

It was heavily used at a former employer of mine, so definitely a solid production-ready solution.

IIRC I then switched to another library doing the same stuff: https://github.com/aantron/better-enums It is not as magical, as it uses a special macro to define the enum, using dedicated syntax. So it only works for enums you yourself define. However, it did work a lot better for me with enums with huge values.

I can't keep up! First we have better enum, then some guy at a conference says we have to use wise enum instead, and now you speak of magic enum!

If you need a laugh today, look at Better Enums library for C++. If you thought moving from C to C++ would let you leave macros behind, think again! Enums in C++ still suck (a bit less than in C though), so someone built a library to help with that. And it's built on macros. So you can only have 64 entries per enum. And the library's code is barely readable.