Enum class from c++11 standart

  1. Enum class is POD.
  2. Enum class is not a class. It’s integer.
  3. Non-virtual class is just syntax sugar for bunch of variables and free functions so I don’t know how it can be “bad” or “good”.

I know what POD means. I just didn’t knew what POD had to do in the context of strongly typed enums.

As Eugene mentioned. A strongly typed enumeration is whatever integral type you need it to be. And integral types are part of the fundamental types, thus POD types.

For some reason I tend to think that you were under the impression that by adding class after the enum keyword, the enumeration becomes a non-POD type. And by the way, you can use struct instead of class. Either works and has the same effect.

Well, as for 3. it is not so, as for some of my larger classes splitting them improved performance,
as decreasing amount of conditionals, etc. They say it is to do with caches (they also say you do only algorithmic optimizations and DOD optimizations these days as all the rest are too minor to care).

for 1 and 2 I probably agree but still do not understand why use more verbose syntax for the same thing,
but probably I consider “just because” an answer as I am not of evangelist public and always thought of C as enough and complete and everything else as burden. So I might not be worthy of the answer.

If your class is large enough and you have heavy algos that access multiple instances of these classes multiple times, it’s true.
In most cases it’s not.

Because grouping is better than no grouping.

I think you’re right, I’m just traditionalist C programmer forced to do C++ occasionnaly, so I might be biased there. Also in my environment recent C++ additions are heavily frowned upon, so this might be added to the bias. When I optimized my Urho stuff I got a lot of improvement from using of plain arrays instead of vectors, combining variables together and using small classes, and got about 20% performance boost in world generation algorithms. Because of that I ended up in DOD sect and truly believe in their majic.

for the case of magic making parts of class into static classes and referencing them by a pointer
heavily increased performance for classes with large amount of short methods.
(as well as converting Component into Subsystem fixed archtecture problem, but that is far fetched too)

I just want to tell there is truth that these things are important. Sorry for diverging the discussion, thank you I always happy to learn new things on these forums through discussions.

Well about grouping - you can use anonymous and non-anonymous enums and put enums into classes and namespaces, right?

AFAIK any solution except enum class plus FlagSet has its own unsafety and/or ugliness.

If you use enum as is, guts are leaking into the outer scope.
If you use scoped enum in struct or namespace, you have to write the scope every time you access the enum type.

To be fair FlagSet sucks as well. But it is by far best workaround for something that should be core feature of the language.

I mean, how could it be language feature?


Edit: By the way this also sucks somewhat because macro has to be used on the enum outside of any namespace in order to allow user code not from Urho3D namespace to use these operators.

hm, it works

namespace Opop

#define DEFINE_FLAGS_OPERATIONS(enumName, typeName) \
    inline enumName operator | (enumName lhs, enumName rhs) { return (enumName)(static_cast<typeName>(lhs) | static_cast<typeName>(rhs)); } \
    inline enumName& operator |= (enumName& lhs, enumName rhs) { lhs = (enumName)(static_cast<typeName>(lhs) | static_cast<typeName>(rhs)); return lhs; }

enum class Flags : unsigned
    A = 1u,
    B = 1u << 1,
    C = 1u << 2


int main()
    Opop::Flags q = Opop::Flags::A | Opop::Flags::B;

    q |= Opop::Flags::C;

1 Like

Oh, I’ve just thought about FlagSet. I think that enabler should be removed and macro with global ops like you do should be used instead.