libCat VS Magic Enum C++

That's awesome! I'm working on something that sounds similar. https://github.com/cons-cat/libcat

I'd love to see your work if you're willing to share it here!

It's worse in the standard library than it has to be. When I refactored my traits to minimize template instantiations and lean on concepts as much as possible, I measured over 30% improvement to clean build compile times. It's not possible for the standard to do this, because it would subtly change the API. For instance, you can't instantiate or take the address of a concept, but you can for a type-trait class. No reason you'd want to do that, but you can, so they can't "break" the standard library by optimizing this.

This doesn't have to be true. Over the past year I've made progress towards demonstrating how even non-freestanding C++ can be written without any C or C++ standard library headers or DLLs (with large benefits). There are a few names which the compilers require to be in the std:: namespace, though, but they're very special features like source_location and construct_at with semantics that can't be expressed otherwise.

It isn't that hard to put a predicate into a type. We have lambdas in an unevaluated context, CTAD, and templated type aliases. https://github.com/Cons-Cat/libCat/blob/main/src/libraries/scaredy/cat/scaredy https://github.com/Cons-Cat/libCat/blob/main/src/global_includes.hpp#L70 https://github.com/Cons-Cat/libCat/blob/main/src/libraries/linux/cat/linux#L289 You do it like this.

I use clang-tidy. These are my current linting rules.

I'm working on this! https://github.com/Cons-Cat/LibCat

What does this have to offer over magic_enum?

But it's a hack, and I prefer not to use hacks in production, because of their significant limitations:

Why reinvent the wheel? magic_enum

I strongly recommend that you instead use magic_enum::enum_cast

Magic Enum provides that.

While I can understand the sentiment behind that it makes for a poor solution because people seeing the enum will assume it's a valid entry. A better solution is to use something like magic enum for that case.

magic_enum by far. It has an extreme amount of black magic, and compiler specific stuff all abstracted away behind its extremely neat user interface.

magic_enum

To my knowledge magic_enum has some severe limitations; for example, it limits the range of enum values, it cannot handle duplicate enum values, it uses compiler-specific hackes, etc. There is a list of all of them here. [1]

And I'm glad to see interest! I can definitely add string -> enum conversion—I'll see if I can do that right now in fact, it might not take long.

[1] https://github.com/Neargye/magic_enum/blob/master/doc/limita...

It also has really cruel limitations, defaulting to MAGIC_ENUM_RANGE_MAX = 128! It will quietly fail if you try to use this with Vulkan enums for example.