Warning: this isn't nearly as much of an answer as a critique of the talk that "user unkown" linked to in his answer.
His first main point is the (supposedly) "ever changing standard". In reality, the examples he gives all relate to changes in C++ before there was a standard. Since 1998 (when the first C++ standard was finalized) changes to the language have been quite minimal -- in fact, many would argue that the real problem is that more changes should have been made. I'm reasonably certain that all code that conformed with the original C++ standard still conforms with the current standard. Though it's somewhat less certain, unless something changes quickly (and quite unexpectedly) the same will be pretty much true with the upcoming C++ standard as well (theoretically, all code that used
export will break, but virtually none exists; from a practical viewpoint it's not an issue). I can think of few other languages, OSes (or much of anything else computer related) that can make any such claim.
He then goes into "ever changing styles". Again, most of his points are pretty close to nonsense. He tries to characterize
for (int i=0; i<n;i++) as "old and busted" and
for (int i(0); i!=n;++i) "new hotness". The reality is that while there are types for which such changes could make sense, for
int, it makes no difference -- and even when you could gain something, it's rarely necessary for writing good or correct code. Even at very best, he's making a mountain out of a molehill.
His next claim is that C++ is "optimizing in the wrong direction" -- specifically, that while he admits that using good libraries is easy, he claims that C++ "makes writing good libraries almost impossible." Here, I believe is one of his most fundamental mistakes. In reality, writing good libraries for almost any language is extremely difficult. At a bare minimum, writing a good library requires understanding some problem domain so well that your code works for a multitude of possible applications in (or related to) that domain. Most of what C++ really does is "raise the bar" -- after seeing how much better a library can be, people are rarely willing to go back to writing the sort of dreck they would have otherwise. He also ignores the fact that a few really good coders write quite a few libraries, that can then be used (easily, as he admits) by "the rest of us". This really is a case where "that's not a bug, it's a feature."
I won't try to hit every point in order (that would take pages), but skip directly to his closing point. He quotes Bjarne as saying: "whole program optimization can be used to eliminate unused virtual function tables and RTTI data. Such analysis is particularly suitable for relatively small programs that do not use dynamic linking."
He critiques this by making an unsupported claim that "This is a really hard problem", even going so far as comparing it to the halting problem. In reality, it's nothing of the sort -- in fact, the linker included with Zortech C++ (pretty much the first C++ compiler for MS-DOS, back in the 1980's) did this. It's true that it's difficult to be certain that every bit of possibly-extraneous data has been eliminated, but still entirely reasonable to do a pretty fair job.
Regardless of that, however, the much more important point is that this is utterly irrelevant for most programmers in any case. As those of us who've disassembled quite a bit of code know, unless you write assembly language with no libraries at all, your executables almost certainly contain a fair amount of "stuff" (both code and data, in typical cases) that you probably don't even know about, not to mention ever actually using. For most people, most of the time, it just doesn't matter -- unless you're developing for the tiniest embedded systems, that extra storage consumption is simply irrelevant.
In the end, it's true that this rant does have a little more substance than Linus's idiocy -- but that's giving it exactly the damning with faint praise that it deserves.