pon., 10 lip 2023 o 14:40 Alejandro Colomar via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> Hi Jonathan,
>
> On 2023-07-10 13:28, Jonathan Wakely via Std-Proposals wrote:
> > On Mon, 10 Jul 2023 at 10:08, Sebastian Wittmeier via Std-Proposals <
> > std-proposals_at_[hidden]> wrote:
> >
> >> Hi Alex,
> >>
> >> I think you misunderstood.
> >>
> >> Jonathan's INT_MIN / INT_MAX do not return 1 or 16, respectively, for
> >> enums.
> >>
> >> Quite the opposite, Jonathan pointed out that the existing values INT_MIN
> >> / INT_MAX can be stored in MyEnum, so 1 or 16 are _not_ the minimum or
> >> maximum possible value for the example.
> >>
> >
> > Precisely.
>
>
> On 2023-07-10 10:02, Jonathan Wakely via Std-Proposals wrote:
> >> I propose that:
> >>
> >> std::enum_max<MyEnum>
> >>
> >> would evaluate to 16, and that:
> >>
> >> std::enum_min<MyEnum>
> >>
> >> would evaluate to 1.
> >>
> > Why?
> >
> > This is perfectly valid:
> > auto e = (MyEnum)INT_MAX;
> > And similarly for INT_MIN and 0 etc.
>
> This had confused me. I was like, is this some of this crazy magic
> that C++ has for enums to make them separate types from integers and
> I didn't know it? But no. :D
>
>
> > Any proposal related to the "min" and "max" of enums needs to
> > discuss the valid values of the enumeration type.
>
> [I'll talk about the C-compatible part, which is what I'm interested about;
> I don't really care about C++'s enum class and strong typing features]
>
> Regardless of the maximum and minimum values that are supported by the
> underlying type of an enum, it is always useful to be able to know 3 things
> of an enumeration:
>
> - Highest defined enumerator value.
> - Lowest defined enumerator value.
> - Count of enumerators in the enumerator list.
> - Are all the enumerators consecutive?
>
> This is very often useful, for example, for creating an array that uses
> that info for the size:
>
> int arr[__builtin_enum_count(enum foo)];
>
> I don't like the idea of proposing this kind of things to the standard
> directly, but rather propose it for a compiler, and only if it proves to
> be a good API then propose standardization. So, if anyone involved in GCC
> or Clang thinks some of
>
> __builtin_enum_max(enum_type)
> __builtin_enum_min(enum_type)
> __builtin_enum_count(enum_type)
> __builtin_enum_is_consecutive(enum_type)
>
> could be useful, feel free to take the idea and implement it.
>
> Regarding your concerns that enumerations can be used as flags, I've long
> thought that there are basically two very different uses for an enum:
>
> - actual enumerations; only values within the enumerator list are valid
> - flags; composition of enumerators are also valid; normally, the
> enumerators are powers of two.
>
> An idea floats my mind from time to time, that having a [[flags]]
> attribute for such an enum would be useful to mark pow-of-2 cases. It
> could make that the enumerators are prev<<1 if the value is unspecified,
> instead of prev++ that is default for enums.
>
> However, I was never convinced by such idea because removing attributes
> should produce working code, and having the default values of an enum
> change depending on the attribute would be problematic. An alternative
> idea would be to use 'unsigned enum', since flags lists should be
> unsigned, to allow bitwise operations without UB.
>

This could work if user need to do all work and attribute only to check
if given work was done correctly. Simply:

```
enum [[flag]] F : int
{
   Two = 2,
   Three = 3, //compilation error, expected 4
};
```

Ignoring this enum only allows compiling "invalid" programs,
it would not change behavior of "correct" ones.


> >
> >
> >>
> >>
> >> This has often used practical applications:
> >>
> >> MyEnum wolpertinger = eMonkey | eFish | eGoat | eFrog; // 30 > 16
> >>
> >>
> >>
> >> e.g. if like in the example the enum values are given as power of 2 flags,
> >> which can be added/ORed.
> >>
> >
> > Yup. I don't see why you would define power of two enumerators unless you
> > intend their bitwise OR to be valid, which will produce a higher value than
> > the "max" (although the bitwise OR of all the enumerators uses the same
> > number of bits as the highest enumerator). So the example in the "proposal"
> > isn't even self-consistent IMHO.
>
> Yup, the example used in the "proposal" is quite broken; agree.
>
> Cheers,
> Alex
>
> --
> <http://www.alejandro-colomar.es/>
> GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals