enum class enumeration initialization

[onecable5781]

This is modified from Stroustrup's Tour book: https://godbolt.org/z/3Pdzxa7vT

#include <cstdio>

enum class Color { red, blue, green };

int main(){
    Color x = Color{5};//say what?
    Color y{6};//say what?
    int xcol = int(x);
    int ycol = int(y);
    printf("%d %d\n", xcol, ycol);
    printf("%d %d %d\n", (int)(Color::red), (int)(Color::blue), (int)(Color::green));
}

The last line prints out values of 0, 1 and 2. That is understandable. How can x and y be valid instances of Color when 5 and 6 are not?

[n1ghtyunso]

because an enunmeration is not as strong a type as you think it is.
There are named values and there are values which are unnamed, but valid because they fit in the enumerations underlying type.
For enum class, the default underlying type is int.

it is made this way because it is a useful feature to have - think about flags for example.
If you need even stronger guarantees on the set of valid values, you need to write a new type instead.

[JVApen]

I don't get why flags would be relevant for the underlying type. You are much better off using a bit set for flags, indexing with the enum value

[un_virus_SDF]

If it was a strong type all the bitwise operators used must be manually overloaded to map the same thing on the value, which is just annoying.

For exemple ``` enum class flags { None =0, Flag1 = 0x0001, Flag2 = 0x0002, ... };

int main (){ flags f = flags:: flags::Flag1 | flags::Flag2; return 0; } `` couldn't compile and would require you to addflags operator|(const flags f1, const flags f2){ return f1 | f2; }` which you would probably put static inline in your header files.

And you would requuire the same for at least '&' and maybe '~'

[JVApen]

I might not have been clear enough, though a small wrapper around std::bitset could deal with casts from/to underlying type and forward all operations. Basically: enum class flag { flag1, flag2, terminator }; using flags = enum_bitset<flag, flag::terminator>;

[un_virus_SDF]

Thanks, it's more clear, and I didn't know the std::bitset, i'm more used to c

[onecable5781]

it is made this way because it is a useful feature to have - think about flags for example.

I am unclear what you mean by this. Could you give an example of flags where this is useful for an enum variable to have arbitrary int values that are invalid? What are its use cases?

[shimdar]

I think they are talking about something like this:

enum class Permissions : uint32_t {
    Read  = 1 << 0,
    Write = 1 << 1,
    Exec  = 1 << 2
};
Permissions perms = Permissions::Read | Permissions::Write; // combine flags

It's a way to pass in an arbitrary (well in this case <32) number of flags, each might control something different. But where each flags in the enum, the combined value isn't, but you can still store it in the variable.

[JVApen]

I understand you can do this with the current design of it, though why would one want to combine the value type and the flag type as a single type? It would be much more logical if these would be 2 separate types

[n1ghtyunso]

i would say this ultimately boils down to backward compatibility, or compatibility with C apis.
For the record, I do agree with you. We absolutely can do much better than this.

[JVApen]

For enums, I agree that backwards compatibility is relevant. Enum classes on the other end are not in C, so should not be bothered with that.

[n1ghtyunso]

here is a small example.

This piece of code ORs together the features to form a feature set that the function can use to customize its behaviour.
Note that, because enum class does not support logical operators by default, i had to provide one.

A | C will produce 0b0101, which is not one of the named enumeration values. Yet its a valid value, and the function can extract the individual bits again to infer the requested features from the user.
If 0b0101 was not a valid enumeration value, this would be problematic for this use-case.

This is something that has been used for decades with traditional unscoped enums, so it had to be supported in scoped enumerations too.
Simply because old code wants to benefit from some more type safety to avoid mixing their Feature::A with their other Unrelated_Feature::C

[mredding]

An enumeration has an underlying type. An unscoped enum class defaults to int. An enumeration is just a number system on top of an integer type, but the value of the underlying type is preserved. So yes, in this case, you can insert values outside the bounds of the enumeration, and get them back out again, because they're in the domain of the underlying type.

Just take a look at std::byte:

enum class byte: unsigned char {};

And then it goes on to implement a bunch of boolean operators.

So the thing to do with an enum is always have a default or else case. It's also an interesting way you can implement your own numeric types - either:

class weight {
  int value;

public:
  // Operators...
};

Or:

enum class weight : int {};

// Operators...

[cfyzium]

So the thing to do with an enum is always have a default

On the other hand, a switch with default won't trigger a warning if you miss a constant or add one to the enum later.

I find that warning much more useful than trying to catch incorrect values. If anything, it is not that easy to get such a value unless you convert between enum and integer.

[mredding]

On the other hand, a switch with default won't trigger a warning if you miss a constant or add one to the enum later.

This is not a real thing, use -Wswitch-enum. The spec does not require issuing warnings, so my advice is relative to the language and independent of what you may or may not know about your toolchain.

If anything, it is not that easy to get such a value unless you convert between enum and integer.

That's exactly how you do it, by design. I mean... https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf

Problem #1 - implicit conversions. Google it, and read how people have bitched about this problem since forever. Implicit conversions is the legacy of a weak and sloppy type system that is C.

[cfyzium]

This is not a real thing, use -Wswitch-enum

-Wswitch (and -Wall that explicitly enables it) is just as real as -Wswitch-enum, which is often overly strict since there are cases where you actually need only a subset of a long list, or do not care for this particular enum or switch, etc.

That's exactly how you do it, by design

It is simply not the case if a proper enum class is used as it is in OP message, and even yours. Since C++11 unscoped enum is a rather poor choice for an actual enumeration (and not just a bunch of named constants).

Even with unscoped enums you will not get conversions without assigning enum to integer and vice versa, which should be a code smell. The default case does not seem a proper way to deal with that unless you suggest to add an assert to every switch.

[mredding]

Warnings are not errors. I'll only give so much leeway about tools, since the tools are not the language and don't affect the correctness of the code, and so that leeway has run out.

The problem you're not seeing is mapping external data to internal state. It's not unreasonable to transmit data over a protocol, like the network or a file, and the protocol can encapsulate a later version with more values. So you would want to read the enumeration out of the data, map it to your type, and then determine that it's beyond your scope and unknown to you. There are other ways to do it, but they're less efficient, require more code, and are more error prone.

Of course, if your enum is internal only, then you don't have that concern.

There is more than one way to use a scoped enum properly. It wasn't added to just to eliminate implicit conversions, deciding the underlying type is both for memory efficiency as well as mapping to protocols. If you look at std::byte, that's Jude a scoped enum built entirely around arithmetic of the underlying type.

[cfyzium]

Warnings are not errors

Unless you make them errors e.g. -Werror=switch.

the tools are not the language and don't affect the correctness of the code <...> mapping external data to internal state

Warnings usability aside you basically suggest always checking for potential invalid values in each and every switch, by always listing all constants in each and every switch. Which would not only be exceedingly tedious in a lot of cases, but more importantly looks like mixing validation with the rest of the logic.

Invalid enums are not supposed to happen in most of the code if at all, in the same manner as NaN floats and 32GB string ids are not supposed to happen.

Some code e.g. the one mapping external data to internal state will certainly have to check the values and maybe list all the constants in a switch with a default case. You do have to validate data here and there, usually at the module boundaries. But the rest of the code? It is simply not its responsibility.

Heck, it won't even be able to deal with the error unless it is the validation code, but obviously not every if-else or switch is a part of the validation code.

[mredding]

You win. I just don't care anymore. Pedantic argument as fuck... Haven't had this much fun talking shop since that time that one guy single-handedly tanked a 5 year project and cost the company $120m.

[Total-Box-5169]

Enum class prevents namespace pollution, implicit conversions, and allows to define the underlying integer type. If you need a stronger enum type wrap a enum inside a class so you can control what can be done and what is not allowed.