Re: [Describe] Review - Part 1: Enumerators

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2021-03-10 17:39:15

śr., 10 mar 2021 o 17:50 Alexander Grund via Boost <boost_at_[hidden]>
napisał(a):

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