Comments from other people on my:

Why C++ Templates (and STL) Are Bad

(Click here for the original webpage these comments are about.)

(Read a personal description of Backblaze here.)

This page contains some of the comments and notes from other people I have received from people, some of these people I know, some I do not know.  If you have something you would like posted here, just send me a note to .

Kyle Gibson Writes (on 5/15/2005):

I just finished reading your rant regarding the STL and the various 
things it does wrong.

It is true that the STL has a steep learning curve (I would say that it 
compares along the lines of CVS) but that does not mean it is designed 
badly, or that the designers had bad taste.

Your first issue with the STL (as depicted by the images) is flawed. 
What you are seeing is a rendering of Visual Studio's header file 
information. This is Microsoft's implementation of the STL (not exactly 
perfect here either). Although this rendering is correct, it's not fair 
to blame STL for the stupidity of Visual Studio. The truth is that you 
should not program off of the STL's header files. Instead, you should 
use the many difference references on the Internet.

For instance:

These resources are easily located using Google. Now, although you don't 
see this in Visual Studio, (which, I admit is a pain the butt) you 
should not fault the STL for the consistency issues of something 
designed by Microsoft.


Your second issue focuses on the naming convention used by the STL. In 
particular, it seems unreasonable that they would name a "read only" 
iterator "InputIterator" and a "write only" iterator "OutputIterator".

If this was true, then, perhaps a Non constant iterator should be called 
a NotConstIterator, and then, the others could be: 
NotConstWriteOnlyIterator, etc.

Then you make the following statement, which I don't clearly understand:
"The very words "Input" and "Output" are even reversed from what might 
make sense in this case!"

If you've ever done any socket/file stream programming, you'd know that 
reading information is input, and writing information is output. How are 
those names reversed then?


Now, onto your Java example. It is true that Java simplifies the String 
class down to almost nothing. But... with the Java string class, you 
don't really have any choice anymore. You can't choose how Java 
implements the string, or how it allocates memory, unlike the STL 
string. Not only this, but, the Java string lacks operator overloading, 
which (although might seen conceptually hard to grasp) is often taken 
for granted.

The STL Example you show:

     std::string filePath = "/tmp/downloaded.exe";
     std::string::size_type startPos = filePath.find("/tmp", 0);   // 
the "zero" means start from beginning
     std::string::size_type endPos = filePath.rfind(".exe", 
filePath.size() - 1);  // search from back to see if it ends in ".exe"
     if ((startPos == 0) && (endPos == filePath.size() - 4))
         // fits the pattern.

I agree that the STL lacks many, many functions for string manipulation. 
But it's not a utlity class. That's something that is left to the user 
of the class. For instance, it is up to you to create a 'startsWith' and 
'endsWith' function.  For instance:

#include <string>
#include <iostream>

bool startsWith(const std::string& str, const std::string& start)
    std::string::size_type pos = str.find(start);
    return (pos == 0);
bool endsWith(const std::string& str, const std::string& end)
    std::string::size_type pos = str.rfind(end);
    return (pos == str.size() - end.size());

int main(int argc, char *argv[])
    std::string t = "/tmp/downloaded.exe";
    if(startsWith(t, "/tmp") && endsWith(t, "exe"))
    std::cout << "Yay" << std::endl;

    return 0;

Is this still more complex than your Java example? Definitely! And with 
complexity comes the potential for making errors. Although this makes 
the STL dangerous, the same is true for C++, and C. This is not the 
fault of the STL. This is the fault of the user for being unaware.

The reason such functions do not exist in the STL because it is not the 
job of the library to act as a string utility. It's a container library: 
it encapsulates data and gives you the ability to manipulate it as 

Java solves that problem by simplifying what you have to do - and C++ 
allows you to make those simplifications yourself.


Juan Altmayer Pizzorno Writes (on 5/29/2005):

My "favorite" STL issue is the auto_ptr thing, which when you do

   a = b;

'b' looses its value.  That's so misleading!...   The least they could have
done is to use "<<" or something like that.

I think code must be readable.  Write-only code costs you money (among other


Keith Sabine Writes (on 10/12/2005):

I read your page on STL issues and I have to agree. I've seen just too much
code, typically written as university projects, that uses STL and
totally kills an algorithm's performance.

Here's an example: an algorithm to computer a Steiner Tree. The original
coding was in C, and was pretty efficient using native C arrays. But a
certain university group thought it would be cool to reimplement it in C++.

Now the original code used arrays with a range of -1 to n. Strange, but
not unheard of. The university group must have wondered how to do such
a thing using vector... and so they chose to use map to implement an
array, just because.

The resulting code, when profiled (why don't STL users profile their code?)
showed that a high proportion of the runtime was in the STL map code,
specifically operator[]. Rewriting it with a simple array class gave a ~5x speedup.

- Keith Sabine

Click here to return to Why C++ Templates (and STL) Are Bad



(Read a personal description of Backblaze here.)

Click Here to Return to Random Stuff