What I learned in my C and C++ years of enterprise coding is that I want to stay away from those codebases.
C++ can be lovely when used in small teams of skilled developers that play by the rules.
On typical enterprise code, with various skill sets of developers that come and go, many from consulting companies, it can be a huge pain to maintain and track down memory corruption issues.
That's fine, but protecting you from other people doing ridiculous things isn't really the fault of modern C++ as it is possibly a feature of a GC language. I think there is utility in not letting people out of a sandbox if they can't handle it, but I also think the fact that C++11 has a stark path that should be used is different than the high wire act of C and older C++.
It is a fault of C++, because there are other systems programming languages also without GC, that aren't as memory corruption friendly as C and C++.
They achieve that by either being older than C, or never being copy-paste compatible with it.
This is the biggest drawback of C++, even modern C++. C compatibility was a good way to achieve adoption, but also what hinders the language in terms of safety.
It doesn't matter how many safety features the language has, you always have a few cowboys coders doing "C with C++ compiler" style.
In the majority of typical enterprises where code review and static analyzers are foreign words, you get into horrible code bases.
I like the language a lot, it is the language I liked most to use after Turbo Pascal, used to teach it to first year students and have a few jobs on my CV where I really enjoyed using it.
Nowadays I rather use it in personal projects as infrastructure language alongside other ones where I can easily follow modern practices, rather than on the job in codebases where developers come and go.
Quite true, the only thing that C++11 does is make it part of the standard library and offer a few language features that make it more pleasant to the eye.
I was already using smart pointers with COM in 1998, but of course most of the third party libraries we depended on, did not.
What I learned in my C and C++ years of enterprise coding is that I want to stay away from those codebases.
C++ can be lovely when used in small teams of skilled developers that play by the rules.
On typical enterprise code, with various skill sets of developers that come and go, many from consulting companies, it can be a huge pain to maintain and track down memory corruption issues.