Believe me, those who truly believe that C++ is great, consider some of those deficiencies to be advantages.
It helps to remember, that C and C++ don't exist on an "VM island", i.e. as an isolated process, like all high-level programming languages do. They are effectively extensions of UNIX-derived operating systems, i.e. they run under "UNIX VM". They even have a garbage collection of sorts: when you exit the program, the memory gets freed. And, according to Linux philosophy, launching processes or forking/dying should be quick, efficient and, in fact, desirable. Also, having many independent binary modules is the norm, so here is your runtime encapsulation.
But C family is still the only tool out there that allows you to extend an OS, i.e. for instance to build a piece of code, a single instance of which will be serving all other simultaneously running processes. This explains why Apache eats so little RAM. None of VM-based languages can do that. It's called systems programming.
Building a web-based CRM in C++ is stupid. Building a filesystem in Python is impossible.
"When an invalid program finally crashes (or enters an infinite loop, or goes to sleep forever), what you're left with is basically the binary snapshot of its state (a common name for it is a "core dump"). You have to make sense of it in order to find the bug."
The whole list is a one big whine that in parts is staggeringly clueless. It reads like its author has challenged himself to come up with as many "Defective" or "Very complicated" items as he could just for the sake of making the list looooong.
Some of them are just wrong, and a few of the wrong ones seem to be intentionally wrong. C++ has quite a few flaws, but I've always considered the FQA to be a troll.
It's amusing how people attack C++ from both directions. You get the main article apparently complaining that C++ isn't retarded simple and verbose like C. Then you also get people like in this link basically complaining that C++ isn't Lisp.
Allow me to clarify: C++ is a replacement for C. C code rewritten as C++ will almost always be shorter and the same speed. The structure and function of the code will also tend to be clearer in C++.
C++ has a high price in terms of binary incompatibility. Its mangling is (still) complex and fairly non-standard across compilers, which means that libraries are unusable unless you know how they were built and have built them all consistently. Plain C libraries, however, are generally plug and play.
To put up with the pain that is C++ mangling (which I sometimes do), I need to be using major features of C++. If you're only using C++ to make shorter, prettier code that could just as easily be C, you're creating an unnecessarily fragile binary.
Clearly C++ has its advantages, I'm just saying that you should require a lot of those features before accepting it as a language. This is especially true now that C has been absorbing some of the advantageous features of C++, such as inlining.
C++ has a high price in terms of binary incompatibility.
I find this statement to be rather untrue because I think most modern compilers when forced to be ISO/ANSI compliant (i do: g++ -ansi -pedantic) ensure your code is portable across systems.
Well I wrote (a command-line) program that was about 2000 lines long in C++ and during most of the development period I used g++ with the -ansi & -pedantic options.
Later I was able to get my program to compile on Visual C++ with absolutely no modification.
Ah, that's different, that's just compilation (and yes, I've seen compilation incompatibilities too; VS usually requires code changes to compile).
I was referring to the binary interface. What I'd want to do (and generally can with C) is compile a library with any compiler, and link it with any other code, with no recompiling.
You see this all the time with Unix, say; maybe Sun compiles a bunch of stuff with their C compiler, but you can easily link to what's in /usr/lib using GCC. But with C++, it's typical for the loader to not link C++ libraries that were built differently; and if you're really unlucky, the loader won't notice and instead you'll see subtle binary errors at runtime.
http://yosefk.com/c++fqa/defective.html
The rest of the FQA site is good too, but the summary is the best enumeration of all the brain damage.