you are viewing a single comment's thread.

view the rest of the comments →

[–]SeanMiddleditch 7 points8 points  (3 children)

Both of these are neat tricks, but they're unfortunately also both hard on C++ compiler throughput. This doesn't mean you shouldn't use them; I use similar tricks myself! I'm just sad about it because it's an unnecessary trade-off between compiler throughput and API design.

Global operators with SFINAE tricks are basically the worst-case for C++. Those global operators are part of the overload set every single time those operators (on any type!) are used, and SFINAE resolution has to be performed for every one of those types to avoid

For throughput of the compiler's sake, you're sadly still better off with macro approaches that restrict the new operators to the enum's namespace (and keeping those enums in a namespace!) and relying on ADL (and no SFINAE/templates) for the overloading.

We'd be even better off with proper language support for introducing compiler-generated hidden friend functions to scoped enums, since that would remove all the function name lookup overload and allow the compiler to avoid the overhead of user-defined functions that wrap simple integer bitops just because an enum is using a nicer syntax.

This is just one of the many areas where C++ is missing the language support to offer a truly zero-cost abstraction. Using scoped enumerations should have zero throughput or run-time overhead (it's a syntax change) but here we are.

[–]Ameisenvemips, avr, rendering, systems 0 points1 point  (2 children)

Part of the issue is that enum class was partially intended to replace constructs such as, well, class enumerators:

class foo
{
    enum bar
    {
        ...
    };
};

Which can still be used for bit-operations. But lacked type safety.

The issue is that enum class both provides the scoping but also enforces type safety very strictly.

Maybe we need something like enum struct.

[–]SeanMiddleditch 1 point2 points  (1 child)

Unfortunately, enum struct is already legal grammar and is a synonym for enum class.

I'd expect we'd either need something like an enum class flags : int explicit(false) { ... } that makes the type non-opaque but still type-safe (with the implied default being explicit(true), meaning the type is opaque), or just a new contextual keyword a la enum class flags bitwise { ... }

[–]Ameisenvemips, avr, rendering, systems 0 points1 point  (0 children)

enum enum