Subject: Re: [boost] [Better Enums] Interest in/feedback on C++11 enums library
From: Klaim - JoÃ«l Lamotte (mjklaim_at_[hidden])
Date: 2015-05-17 18:10:28
On Thu, May 14, 2015 at 3:25 PM, Anton Bachin <antonbachin_at_[hidden]> wrote:
> 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 <
> 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 <
> . 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:
> . Some of that could be useful when C++ declarations are generated by
> 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:
> 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
> 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
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.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk