[Better Enums] Interest in/feedback on C++11 enums library
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. Best, Anton
On Thu, May 14, 2015 at 3:25 PM, 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.
This is interesting to me and my projects but I will not be able to test it immediately. I'll try to give feedback on the doc soon. By the way, your email was marked as potential spam by gmail so maybe other members didn't get it.
Best, Anton
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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:
Looks great. -Thorsten
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-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.
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.
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
participants (5)
-
Anton Bachin -
Damien Buhl -
Gottlob Frege -
Klaim - Joël Lamotte -
Thorsten Ottosen