C++ has a weird niche. It's as fast as C, but is as high-level as Java... at first. It has exceptions, it has multiple inheritance, and it has "methods" (though C++ doesn't call them this, for some reason). This makes it the perfect language in many people's minds; fast and expressive. Unfortunately, the stuff that makes it fast is on all the time at the cost of making every function a potential foot-gun. (I can convert an integer to a pointer at runtime! I can remove "const", too...)

When you are writing code that needs to execute quickly, you don't want to do anything that's not related to the task at hand. You want to shovel bits into the CPU as quickly as possible. This means using native, unboxed types, not checking preconditions before every operation ("why would the preconditions ever not be satisfied?"), using trickery like integer-to-pointer casts, etc. C works this way, and lets you write code that runs very quickly. C++ works this way too.

The other half of a C++ app, though, is the complex glue code. Most sections of a "real application" are complicated, but they don't execute often enough for speed to be too critical. That's where you want safety; lots of self-checks, boxed types that don't let you misuse them, etc. There is a lot of complexity to manage, and a team of programmers can't do it; so you want your language and runtime to help you out.

Unfortunately, C++ doesn't help you out; you are expected to write the non-time-critical sections of your application they same way you write the critical sections. Ignore types, manage your own memory, skip polymorphism for speed, etc. Those are all the default behaviors, and they make it hard to write reliable code. (It is really worth overwriting random memory just to avoid a single comparison between an array's length and the index you are referencing? In a video decoder, yes. In the drop-down menu where the user picks the kind of TPS report to send, probably not. But guess what the default behavior is.)

The failure mode of C++ is also quite severe. In Java, flaky code that doesn't work just returns the wrong answer or dies. In C++, flaky code that doesn't work can corrupt other parts of the program randomly, and it can even allow malicious users to inject arbitrary code. There is no failure mode; the program keeps running incorrectly until something is so utterly wrong that the OS or machine kills the program. ("Segmentation fault (core dumped)".)

So basically, if you're using C++ correctly, for speed-critical sections of your application, you could just do it in C; and if you're using it for applications, you would be better off with anything else; Java, C#, Common Lisp, Haskell... all much better for higher-level code. You probably won't notice the runtime speed difference, but you probably will notice the lack of random crashes because your off-by-one bug overwrote some global state...