Re: [Describe] Review - Part 1: Enumerators

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2021-03-10 16:49:51

> 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.
> 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.

And as those macros are very lightweight I appreciate their existence.

Just another view from a user :)