STL does blow. Templates are fine if used sparingly (i.e. non-STL container classes). Virtuals shouldn't be optional (a la Java). I'd add to the list that references in C++ are silliness (const reference usage should be a detail handled by the compiler automatically, non-const references just lead to ambiguous APIs).

The problem really seems to be that there are still some niches where you need something with relatively fine grained control and raw horsepower of C++, but there's not been anything to come along to fill that niche.

A simplified C++ standard would be a step in the right direction. Unfortunately it seems that the standard is moving in the opposite direction.

For what it's worth, I find programming with Qt pretty close to "C++ as it should be".

I make extensive use of the STL, so I'm curious to hear why you don't like it.

I use it on a daily basis, so my ranting is coming from a different angle than the author's. The main problems that I see about the STL is that I find it more of a demo library for showing off how far you can push the generic programming metaphor than a pragmatically designed toolkit.

Here are a few points:

- Heavy template usage makes debugging hard. The Intel compiler does the best job I've seen of reporting sane errors, but it's still ugly.

- Heavy template usage makes the symbol count and binary size explode. Bigger binaries mean more cache pressure, so this slows things down, makes for bigger downloads, etc. (For a project at work recently I had to refactor some of our template based code to be OO instead as heavy template usage and associated expansion was quite literally adding 20 MB to our application's size.)

- The API is fugly.

I can see why you're saying what you're saying, but I didn't find debugging particularly hard, and binary size explosion is probably your particular compiler's problem: MSVC 7.1 works very nice with templates, generating code only when absolutely needed, and sharing generated method/function instances across multiple template instantiations when types allow.

Moreover, STL is beautiful. It was originally designed for Smalltalk if I remember correctly, and it's "ugliness" is nothing more than a bad implementation. Separating alogrithms away from the data types they operate on is a novel idea. Granted, you get it for free in dynamic languages, but STL goes as far as you can get in a rigid world of stone types.

I have been facsinated by C++, by its ugliness, its sheer size, hidden powers and fast code it generates. My interest in it has faded away as CPUs got faster.

In my opinion the biggest issue with C++ is the lack of any kind of modules, and the author of the original post correctly recognizes that. Those endless includes multiplied by need for templates, produce ridiculous build times and make it impossible to hide implementation details (everythin g is still exposed via hpp-files).

I can't say you're wrong, because it's all personal preference, but I guess those issues don't bother me as much. I copy and paste the errors and manipulate the text until I understand what's going on. This is cumbersome, and I wish the compiler would simply say "this has to be const," but it's not that smart. They should be that smart, and while I see that as a compiler problem, I understand it doesn't make a difference to the programmer who has to use it.

Binary size is a problem with heavily templatized libraries if debugging information is turned on; if not, there's no problem. I make heavy use of Boost.Spirit, and I saw my binary drop from 21MB to 3.7MB when I turned debugging information off.

And I guess API is just a matter of taste, although I do find myself making short wrapper functions for types of calls I make often. (Such as for_all as a wrapper to for_each on the .begin() and .end() of a container.)

i agree with that. just std::string alone has saved me from years of pain.