DanRStevens
commented
6 years ago As it relates, here is a StackOverflow question about whether or not using the scope resolution operator (::) is standards compliant on regular enum types:
Scope resolution operator on enums a compiler specific extension?
It seems it is/was non-standard, though common before C++11. I saw a comment in there that suggested C++11 added the ability to use scope resolution even on regular enums, though that comment didn't give a reference to anywhere.
If it is part of C++11, which we are explicitly using (or rather C++14), then any explicit use of scope resolution with enum classes wouldn't be impacted if the class part was removed. If it's a non-standard extension, then my little test that resulted in no warnings or errors might be less portable than I'd hoped.
Brett208
Relating to Issue #175, I did a bit of investigation into the current g++ warnings. An example warning is:
The compiler complains when
enum classvariables (aka "scoped enums") are packed into bit fields. Turns out, the warning stems from the base type of theenum, rather thanenum class. It just so happens that if anenum classhas no explicit base type specified, then it will have an implicit base type ofint. Regularenumtypes may also have a base type specified, but do not have an implicit base type when unspecified.The following would need both the
classand the base typeuint32_tremoved to avoid the warning:I did some quick edits, and found simply removing the
classand base types allowed code to compile without warnings or errors. We'd lose the scoped nature of the enums, though we eliminate compiler warnings.Looking at this, I get the sense my explicit use of a base type was probably a bad idea. That's probably more useful when you're using an opaque enum.
An opaque enum is an enum declaration, without a corresponding definition of enum values. This is sometimes used in the public portion of an API declaration, while the actual enum values are kept private. Such a declaration allows you to pass enum values around as parameters, and declare variables to hold that type. Since the size is known, it's no problem for the compiler to reserve space for these fields, or generate code to move the values around. Actual use of the specific enum values would be reserved for internal use by the library. The client doesn't need to know what those values are, only that is can pass appropriate values along that it's been given.
We don't need opaque enums, nor are we using enums as opaque enums. It should be reasonable for use to remove explicit base types.
The more controversial part of removing the warnings, is to remove the
classpart, and turn the scoped enums into regular enums. This of course affects namespacing, as all enum value names now become part of the parent namespace.We could possibly wrap enums in a namespace, or perhaps rely on a library namespace which is known to not have collisions.