On 12 Jun 2025 11:53, Ivan Matek via Boost wrote:
On Thu, Jun 12, 2025 at 10:24 AM Alexander Grund via Boost < boost@lists.boost.org> wrote:
Compares the 2 approaches and I very much like the enum approach which does not pollute the global scope with constants that should be scoped too but isn't possibly with the strong type. See:
auto configuration = kUseSimd | kUsePrefetching;
auto config = ConfigEnum::UseSimd | ConfigEnum::UsePrefetching;
As I said before you can limit the scope by introducting a namespace, i.e. namespace ConfigEnum {
The namespace cannot have the same name as the wrapper class, and you can't define named values as static members of the class. https://godbolt.org/z/xhbE8M77r So you can't achieve the same syntax benefits as with enums, where the enum values are syntactically scoped within the enum type. And beside that, the amount of boilerplate that is required by the struct approach is considerably greater than the enum, with no clear benefit in the end.
I am mostly talking about conceptual meaning of enum: set<int> is not int.
The standard defines enumerations as "a distinct type with named constants". That is, its a way to define a number of named constants and associate them with a type. The standard then goes on to say that an enumeration has an underlying type. It doesn't say that the set of values of the enum type is limited to the named constants (as it says e.g. for bool); other values, as long as those values are representable by the underlying type, are implicitly allowed. So when you're saying an enum cannot have values other than the named constants (I'm assuming that's what you mean by "set<int>" above), you are talking about one particular usage scenario of the enum, where you simply don't use values other than the named constants. That's not the only valid usage scenario, and enums implementing bit masks are not a misuse of enums.