Couldn't care less about the type checking differences (apart from using abstract classes with virtual methods, but that's not C syntax), they're quite small and the C++ way is in fact an annoyance e.g. when interfacing with straightforward void pointer APIs. That reminds me of enum class, another feature that brings something nice to the table (properly scoped enum names for better IDE completion) but is almost made unusable by the fact that they can't be easily used with bitwise operators.
The thing about C++ is that many of its features start with a good intention, but most of them are so specific that they have to go down one almost arbitrary route (non-orthogonal decisions, like enum class introducing at least 3 changes at once) and pessimize the other use cases. Good luck refactoring your codebase when you realize you have to change your approach and it's no longer supported by any kind of specialized syntax. That's a problem that C mostly doesn't have -- most of its features are needed when programming a computer, and they're minimal and orthogonal, with few ways to paint yourself in a corner.
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.
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.
The thing about C++ is that many of its features start with a good intention, but most of them are so specific that they have to go down one almost arbitrary route (non-orthogonal decisions, like enum class introducing at least 3 changes at once) and pessimize the other use cases. Good luck refactoring your codebase when you realize you have to change your approach and it's no longer supported by any kind of specialized syntax. That's a problem that C mostly doesn't have -- most of its features are needed when programming a computer, and they're minimal and orthogonal, with few ways to paint yourself in a corner.