Show HN: The Ultimate C++14 (and later) Enum Library
1–10 of 21 posts
Re: Show HN: The Ultimate C++14 (and later) Enum Library
#2No string -> enum would probably be a non-starter for me though
Re: Show HN: The Ultimate C++14 (and later) Enum Library
#3Any chance anyone knows how this compares to magic_enum (which iirc is c++17+ only? Though c++17 seems to be supported every platform i work on now) No string -> enum would probably be a non-starter for me though
Update: And I'm glad to see interest! I just updated the repo to add a parse_enum function for converting strings to enums as well.
[1] https://github.com/Neargye/magic_enum/blob/master/doc/limita...
Re: Show HN: The Ultimate C++14 (and later) Enum Library
#4* what the problem is that needs solving,
* how the lib solves it and how that's preferable over dealing with the problem another way,
* how it compares to other libs that solve the same problem.
Therefore my interest in using this for my own projects right now is unfortunately close to zero.
Re: Show HN: The Ultimate C++14 (and later) Enum Library
#5Re: Show HN: The Ultimate C++14 (and later) Enum Library
#6This is probably an amazing library, yet the documentation gives me no clue * what the problem is that needs solving, * how the lib solves it and how that's preferable over dealing with the problem another way, * how it compares to other libs that solve the same problem. Therefore my interest in using this for my own projects right now is unfortunately close to zero.
- The problem is basically twofold. Part (a) is that there are no facilities for dealing with enums in C++. "Dealing with" could be anything, such as: bitwise-combining enums as flags, converting enums to/from strings, verifying that a given value is valid for an enum, decomposing flags into their constituent values, and anything else people might typically want to do with enums. Part (b) is that people end up manually writing enum-specific functions for these over and over again, and that often results in brittle and non-reusable code that quickly gets out of sync with the actual enum as it evolves over time (e.g., handwritten parsing code might stop working when a new member is added). This library aims to address most if not all of these problems.
- There are 3 main "tricks" I've used (and a ton of boilerplate on top of that): (a) I use the auto-return-type-with-hidden-friends trick to "tag" the enum with metadata for later retrieval, (b) I overload the comma operator to be able to utilize the same text for both the enum definition as well as for storing relevant metadata, and (c) I use constexpr string parsing to extract the enum names from the definition passed to the macro. Part (a) is confusing and better explained in the link I put in the credits. Part (b) is somewhat tricky but hopefully not too bad. Part (c) seems obvious in hindsight now that I mention it, but I haven't seen it used elsewhere in this manner. (Edit: While digging further just now, I found someone has indeed tried a similar approach with constexpr string parsing in [1], though it appears less comprehensive.)
- No other libraries that I'm aware of support all the features of this one. Typical restrictions include: limiting the ranges of the underlying values, limiting the number of enumerators to some amount, not supporting enum members with duplicate values, not supporting 'enum class', etc.
Hope this helps! If I can clarify anything else please let me know.
[1] https://github.com/therocode/meta_enum/blob/master/include/m...
Re: Show HN: The Ultimate C++14 (and later) Enum Library
#7This is probably an amazing library, yet the documentation gives me no clue * what the problem is that needs solving, * how the lib solves it and how that's preferable over dealing with the problem another way, * how it compares to other libs that solve the same problem. Therefore my interest in using this for my own projects right now is unfortunately close to zero.
Re: Show HN: The Ultimate C++14 (and later) Enum Library
#8It is amazing how much effort is going to simplify adding "enum_to_string(e)" support in C++ or C. What is the reason this not being part of C++ standard?
- The problem is somewhat underspecified. There are lots of degrees of freedom—what delimiters you support, what character encodings you support, what inputs to accept (numeric vs. names), how exactly to deal with flags, etc. These make a generic solution more involved. It's in some sense a more complex version of the problem of number parsing, which has had quite a long journey and is still not entirely ergonomic in C++. (Even std::from_chars only came out in C++17, for example.)
- Lack of more general reflection capabilities, especially ones that provide string metadata, especially at compile-time. Given reflection isn't coming in C++23, it might be a while before we get support on this front.
Re: Show HN: The Ultimate C++14 (and later) Enum Library
#9It is amazing how much effort is going to simplify adding "enum_to_string(e)" support in C++ or C. What is the reason this not being part of C++ standard?
Re: Show HN: The Ultimate C++14 (and later) Enum Library
#10This is probably an amazing library, yet the documentation gives me no clue * what the problem is that needs solving, * how the lib solves it and how that's preferable over dealing with the problem another way, * how it compares to other libs that solve the same problem. Therefore my interest in using this for my own projects right now is unfortunately close to zero.
Ah sorry about that, thanks for the feedback! I can try to answer these here (and hopefully update the documentation as well when I get the chance): - The problem is basically twofold. Part (a) is that there are no facilities for dealing with enums in C++. "Dealing with" could be anything, such as: bitwise-combining enums as flags, converting enums to/from strings, verifying that a given value is valid for an enum, d…