Over in the Unrelated topic, I donned metaphorical asbestos panties to say that I don't like C++. Here, I don't need the panties. I'll go metaphorically commando and admit that I really, really, really despise C++. Even one of the language's defenders in that forum (OmnipotentEntity, I believe) called it "a behemoth". Let's examine it in detail.
Once upon a time, an AT&T researcher named Bjarne Stroustrup wanted a language with which to do simulations programming. He didn't have a Smalltalk environment handy so he and his chums wrote a preprocessor for a language which he called "C with Classes". That was all it was: it added code attributes to C's existing product-type facility, which is called "struct" in C. It did not address any of C's weaknesses, such as weak pointer typing or resource allocation. It was a graft on the side of C, and that was all it was ever supposed to be.
Now, other people at AT&T wanted to try out this new object-oriented stuff too, so they got Stroustrup to add more and more features to this new language of his. Somewhere in there, it got renamed from "C with Classes" to "C++". First, Stroustrup added multiple inheritance to the language. Then, he added ad-hoc genericity. Then, he added exception handling and run-time type identification. He should have added those features in exactly the opposite order, but he didn't, so as time went on the language got more and more and more baroque.
Still, the primary design motive for C++ was binary compatibility with C. C++ never acquired compiler-managed resource allocation, and because C++ programs have to be able to link with C programs, it never can. It now comes with a standard library of generic container classes and algorithms on those container classes, which takes care of many of the problems with resource allocation -- but by no means is the entire problem gone.
Meanwhile, people outside AT&T wanted to try out this new language, too. I was one of them; I saved up my allowance for many months to buy the first version of Borland Turbo C++ as soon as I could. (I was a weird kid, okay.) The language got so popular that it spawned many dialects, and programs written for one compiler required very heavy tweaking even to compile properly on another, let alone link and run. People demanded a standard, and for their sins, one was given to them.
Standards committees are committees. The C++ language was already beastly, but after standardisation, it has become ridiculously unwieldy. It is so unwieldy that as I write this, no compiler adheres to the entire standard even seven (I think) years after it was published. (G++ comes close, though.) Furthermore, because of pressure from industry, the standard was released far too early and therefore makes C++ harder to use, not easier.
More corollaries of the binary-compatibility-with-C rule: firstly, it turns out that programs compiled with one C++ compiler will not link with object files of programs compiled with other C++ compilers. Microsoft may love this state of affairs, because it means that if I want to use a library that was compiled with MS VC++, I have to purchase MS VC++, but ordinary people do not love spending large amounts of money on redundant, ill-written compilers. (MS VC++ is
not a good compiler, compared with IBM's or GNU's, and its development environment pales in comparison with Emacs.) Secondly, it makes for nightmarish versioning problems. If I change the interface of any one class in a program, I will likely have to compile the
entire program again. Imagine having to wait for eight-hour compile cycles each time you find and squash a bug.
That is not to say that there is nothing good about C++. One very accidental feature of C++ is that a C++ compiler is an
interpreter for a very strange functional language which has come to be called "template metaprogramming". That is, a C++ program can be a program to generate new C++ programs at compile time, which is weird, but
amazingly useful in certain circumstances.
And, yes, compiled C++ programs are fast. That is, if they don't have any bugs in them. Since it is so hard even to compile C++, a program that even theoretically has no bugs in it may fail to work properly after being processed by any given compiler. That is not to diminish the difficulty of writing correct C++, either, especially given the monstrously complicated rules governing exception handling.
There is a place in this world for a good, compiled systems programming language that allows the programmer much leeway and control. It would be nice if that language were object-oriented, because OO design is fashionable these days, but it probably doesn't need to be.
Hey! I know! Why don't we use C ....