Re: [boost] [Better Enums] Interest in/feedback on C++11 enums library

Subject: Re: [boost] [Better Enums] Interest in/feedback on C++11 enums library
From: Damien Buhl (damien.buhl_at_[hidden])
Date: 2015-05-21 08:27:53

On 14/05/2015 15:25, Anton Bachin wrote:
> Hello,
> 
> I’ve just released an enum library that takes advantage of constexpr functions and literal types to provide a nice declaration syntax and decent feature set: https://github.com/aantron/better-enums <https://github.com/aantron/better-enums>
> 
> I’d like to get feedback on it from the experienced developers here at Boost. Is this approach useful? Are any major features missing? Would this be an interesting candidate for enums in Boost? I am very willing to do further development on this project.
> 
> The library's basic features are string conversions, value and name listing, some type safety, and a declaration syntax that is based on built-in enums and is easy to learn and use.
> 
> A much more "advanced” feature is that the generated class is a literal type, and almost everything is constexpr. Here is a simple example, that takes advantage of this, of a compile-time encoding of project policy: https://github.com/aantron/better-enums/blob/master/example/6-traits.cc <https://github.com/aantron/better-enums/blob/master/example/6-traits.cc> . Once I make the iterators constexpr as well, by providing a way to increment them other than mutation (++), it will be easy to write rather involved compile-time algorithms that process Better Enums declarations. Here is an example of a whole bunch of simple compile-time processing already possible: https://github.com/aantron/better-enums/blob/master/example/4-constexpr.cc <https://github.com/aantron/better-enums/blob/master/example/4-constexpr.cc> . Some of that could be useful when C++ declarations are generated by script.
> 
> The library is all standard C++11 (to the best of my knowledge), except for the usage of weak symbols for some generated constexpr static arrays. I have tested it successfully on clang and g++, but I would need help getting access to more compilers. I believe weak symbols are not a problem for MSVC, but I still don’t believe the library will compile on MSVC since I don’t think MSVC supports enough of C++11 yet.
> 
> Performance is what I would call excellent. I compared compilation times of these two files to each other:
> 
> https://github.com/aantron/better-enums/blob/master/test/performance/4-declare_enums.cc <https://github.com/aantron/better-enums/blob/master/test/performance/4-declare_enums.cc>
> https://github.com/aantron/better-enums/blob/master/test/performance/5-iostream.cc <https://github.com/aantron/better-enums/blob/master/test/performance/5-iostream.cc>
> 
> The first file includes enum.h and declares a bunch of enums, and the second merely includes iostream. On my machine, clang compiled all those enums in about half the time it took to process iostream. g++ was faster on iostream, but only slightly. Using a lot of compile-time expressions would have additional cost, but it has been too small to measure for “realistic” examples from my own usage. I haven’t yet made an example that repeatedly deals with a very large enum at compile time to properly measure that impact.
> 
> I’ve also explored an alternative interface where the constexpr properties provided by the library are in a traits class parametrized by a normal C++11 enum class, but the interface seemed too verbose. There is also a bitset type that has a very slightly nicer interface than std::bitset for usage with enums, but I didn’t think the improvement was worth the user’s learning effort. I can put these in branches if there is interest, however.
> 
> Please let me know what you think.
> 
> Best,
> Anton
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> 
..
This looks pretty interesting, as we have the issue always again
(getting string representation of enums out-of-sync with the enum
itself, getting conversion back and forth). At work and on personal
project we use a mini library for this, but it's not as good as yours.

I don't have time to look in more details in your library right now, but
I'll try as Joël to give feedback soon.