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: http://www.msoe.edu/eecs/ce/courseinfo/stl/string.htm

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

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

Kyle