This is somewhat exaggerated, especially because while there are several poorly designed areas in C++ and the STL, it's not all that bad and it can lead to safer, less fragile code than the C equivalent with less effort (but arguably, more skill is required in order to learn and proficiently use C++). It can even be faster than C in the hands of a skilled developer that knows where and how use the right features.<p>It doesn't hurt that the STL is extremely optimized, and often provides you tools that accomplish what you cared about without lots of the gotchas and pitfalls you're almost certainly doomed to fall for if you're not aware of their existence. Almost every single C project I've seen (including some of mine, I've to admit) end up involuntarily reimplementing some basic algorithm or container, and most often than not it ends up being less efficient, or unnecessarily using the heap.<p>One thing I think most people largely misunderstood is exceptions; they're actually totally fine if used in _exceptional_ circumstances, as if they were some kind of softer assertion, when you expect some kind of contract to be always true, but calling abort is just too unreasonable. This is basically the same approach Rust and Go use with panic(), and in both languages this facility by default causes the runtime to unwind the stack, as with C++ exceptions.<p>I think lots of people have been turned off by certain bad designs in older C++ revisions, where exceptions where indiscriminately used for error handing. They were a nightmare to use right, and the lack of helpers like unique_ptr made exception safety very hard.<p>Modern practices, an arguably better language after C++11 and guidelines/libraries such as the GSL vastly help in mitigating most of these issues, as long as people actually stick to them (i.e., no C style code without RAII).<p>I may also argue that the whole "C++ exceptions are expensive" argument is 100% moot in 2020, I've been running code on microcontrollers with half a megabyte of ram with them turned on and they add an almost insignificant amount of overhead; they only cause a small amount of binary bloat, but that's nothing compared to the size of certain modern libraries (and storage is cheap).