śr., 10 mar 2021 o 17:50 Alexander Grund via Boost
Working with C++ enumerations is harder than one might think, because they are not what many people believe. They are just a bunch of integral constants and an integral type. We can get things like this:
enum Season { Spring = 1, Summer, Autumn, // British Fall = Autumn, // American Winter, }; Valid concern, however I think the most part are actually "real enumerators": A one out of a set of values. (I wish C++11 had used enum classes for that instead, missed opportunity IMO) rough sketch: It doesn't really matter if your enum starts at 1, contrary: It might be faster if it does not (for default init to first value and switch-cases). Fall==Autumn is rather a UI than a code issue. But don't want to go to deep, as you are right in principle: Enums in C++ are not enumerators. The interface of describe_enumerators<> is optimal. +1 BOOST_DESCRIBE_ENUM(X, (A, B, C)); // I somehow expected that to work. IMO that makes the interface bulkier than needed and likely slower to compile/preprocess. For structs/classes you need that due to multiple argument lists Describing enums from the global namespace introduces names starting with underscore (_enum_descriptor_fn) into global namespace. This is Undefined Behavior, and is likely to trigger some code sanitizers. Instead use an ugly name, like boost_describe_enum_descriptor_fn. Double underscore or underscore+capital is UB, this here isn't. However I agree with the name hogging as there MIGHT be user defined functions of that name.
http://eel.is/c++draft/lex.name#3.2
I do not appreciate the BOOST_DEFINE_ macros for enumerations. We get as
much as four of them, and neither is able to handle the use case that I consider basic, which I often have in my code: where I omit value zero and start from 1:
struct Error { badSoething = 1, badSomethingElse, tooLongSomethng, ... };
So, I am not sure how many real life enums these macros cover.
IMO they are valueable. As much as I dislike macros it avoids the potential errors by forgetting to update the describe part.
Again: I don't think starting at 1 (or anything specific) is useful if you really need an enumeration of values. It might be a convention for some reasons, but I'd guess the most common case is actually the start at "anything" (i.e. 0) case, at least that is my experience. Exceptions I've found are legacy code, bit fields, mapping to system values (error codes) and similar.
The idea behind omitting zero is that we then can tell apart any proper enum value from the situation where we have default-initialized an enum and forgot to put a proper value. Regards, &rzej;
And as those macros are very lightweight I appreciate their existence.
Just another view from a user :)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost