On Thu, May 14, 2015 at 9:25 AM, Anton Bachin
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-decla... https://github.com/aantron/better-enums/blob/master/test/performance/4-decla... https://github.com/aantron/better-enums/blob/master/test/performance/5-iostr... https://github.com/aantron/better-enums/blob/master/test/performance/5-iostr...
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.
I suspect this code: Depth depth = default_<Depth>(); could be made to look like this: Depth depth = _default; ie all enums have a constructor that takes a default_t type. The constructor then calls default_<T>(). Or something like that. And then change the names to get Depth depth = default_; // calls default_impl<T>();
Best, Anton
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost