3 ms·

I should say differences -- in behaviour when compared to traditional enums.

• zabzonk 3y ago
  well, they are different (and better). but if you want to use old C-style enums, go right ahead - you can do that too. i don't see why you are complaining about a new feature that in no way clashes with an old one.
  • jstimpfle 3y ago
    I do not actually think they are better. They are broken for most of my use cases. Most of the time I'm better off using traditional enums with explicit sizes (a C++ extension that I deem sane), optionally wrapped in a namespace. The mere existence of all those features costs a lot of time just to understand and navigate them. They can diminish productivity. C++ is a huge language. It has tons of features that suck up a lot of time until you understand the space where the features can be used to good effect. And "good effect" often means just writing the same thing in fewer characters, or a little more type-safe (which often wouldn't be needed if the design were sane). And if the requirements slightly change and that good feature breaks, enjoy your rewrite! Or add another set of abstractions or even macros to work around the breakage -- like MS did in case of enum class bitwise operators for example. That's why many people restrict themselves to C entirely -- no time to waste on finding out why C++ features X, Y, and Z all don't work for the given problem. Time could be better spent than with obsessing over all the ways in which an arbitrary set of features can be abused to write the implementation in fewer lines of code, meanwhile making it harder to read & write. Just think about the algorithm & the data layout, and bang out the code.