They’ve been around for 7 years now, so they’re not that new.
The only reason they’re declared as enum class is because the comittee hates adding new keywords unless it’s sufficiently justified.
That’s the same reason templates use class (e.g. template<class T>), it wasn’t until later that typename was permitted as well.
They’re not drastically different from regular enums.
The only differences are type safety(i.e. not being implicitly convertible to int) and scoping (i.e. requiring the scope operator to be accessed).
Otherwise they’re functionally equivalent to unscoped enums.
There’s no reason to assume that a beginner would know about structs and unions but not enum classes - they could be taught in any order.
Aside from which, you’re actually using it for unscoped enums as well, not just scoped enums.
To a degree it does.
Globals have global scope, which causes problems because you can’t necessarily reason about where they’re being used.
It might seem obvious where they’re being used if you wrote the code,
but if you didn’t write the code then it can be quite surprising to find a global suddenly turn up somewhere you weren’t expecting one.
Making the global variable a member variable of another class restricts the places where it can be accessed to member functions, places that have a reference to an instance of that class (if it’s public), and places where the variable is explicitly passed to a function.
All of these are better for reusaibility because it changes the relationship from a fixed relationship to a single variable, to a more flexible relationship that can apply to different variables.
C style is that is not inherantly simpler or more readable.
function(value0, value1, value2) is not inherantly simpler or more readable than value1.function(value0, value2).
That’s more a problem with the practice of using if(x) on non-bools.
Other languages sensibly don’t allow conditional statements to accept anything but boolean types and dont’ allow implicit boolean conversion.
The solution is to avoid using if on non-bools, not to add redundancy.
That’s not true though, a conditional expression doesn’t always compare one value with another.
In telling them that, you’re potentially setting them up for a fall later when they encounter code that breaks that assumption.
I wouldn’t call object.method() ‘fancy’ - it’s a common syntax found in a multitude of languages.
By comparison, the type inference of auto is much more ‘fancy’.
That’s not a problem with the code, that’s a problem with the person’s approach.
If someone doesn’t understand something then they should seek to understand it before they try to change it.
If people run away from what they don’t understand then they don’t learn anything.
They can simply ask how it works, and why - communication is an invaluable tool.
Even restricting code to a simpler subset doesn’t guarantee that everyone will understand it.
Arguably you could simplify the code further by getting rid of type inference with auto and using C-style casting instead of static_cast and reinterpret_cast, but every time you opt for a simplification it tends to come with a cost.
auto wouldn’t be too much of an issue since it’s mainly a tool for laziness (with a few meaningful applications when writing templates and avoiding redundancy),
but getting rid of static_cast and reinterpret_cast would discard something very valuable - an expression of intent, and would open up a chance for potentially dangerous bugs to slip in (e.g. casting away const by accident).
Would making the code marginally more appealing to people who don’t understand those features be worth the trouble it would cause the people who do understand them?
Would it be worth denying the people who don’t understand a learning opportunity?
