"My precious language isn't broken! It's not! Not! Not!" Strostrup writes something like this about once a year. There's some denial there.
The basic problem with C++ is that it's hard to tell if something really bad is happening. Think of C++ from the view of the maintenance programmer assigned to figure out why a C++ program is crashing intermittently. Or worse, the security expert trying to figure out how a system was penetrated. C++ has hiding ("abstraction") without safety. This is a bad combination, one seen in few other major languages.
We make progress in programming partly by having the language eliminate some problem. High-level languages mean you don't have to worry about register allocation, saving and restoring registers, or calling sequence conventions. Assembler programmers have to obsess on those issues. C++ doesn't eliminate any problems from C. It helps with some of them, but not to the point that they're just gone.
The three big questions in C are "How big is it?", "Who owns it?", and "Who locks it?". C++ helps a lot with the first one, even though it doesn't have enough subscript checking to guarantee the absence of buffer overflows.
C++ has struggled with the second one, with three rounds of auto_ptr, unique_ptr, and now reference-counted smart pointers. But because these are an afterthought, implemented using templates, they're neither optimized nor airtight. The mold keeps seeping through the wallpaper, in the form of raw pointers. Rust has a designed-in solution to this problem. (Rust's borrow checker is perhaps where C++ should have gone, but C++ will never get there.)
C++ as a language has no clue about who locks what. The language totally ignores concurrency. That's said to be an operating system problem. This is now a very dated concept.
(As I say occasionally, I really hope the Rust crowd doesn't screw up. They address all three of those big questions in effective ways. But I see too much use of "unsafe" in Rust code, which indicates weaknesses in the language design. The use of Rust's "unsafe" for "performance" is a big problem. From a semantic standpoint, only "Vec" needs "unsafe", because somebody has to convert raw memory to an array of objects. Everything else can be built on top of "Vec". But there is unsafe code for "performance" in hash classes and such.)