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).
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.)
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.