Beware the STL my son! The jaws that bite, the claws that catch!

I used to like C++ a lot. It was a very simple, efficient language, and you could always say exactly how the code you're writing mapped to your CPU.

Of course that was at Microsoft and before, and the dialect that I used was more C than C++ - sprinkled with some syntactic sugar like ability to define variables at the site of the first use, and maybe some classes, and an occasional - very infrequent - template. But still C at the very core.

This is not how Google uses C++ though. Here, C++ means STL. Big time. None of this C style is tolerated (there isn't even readability process for C!). And everything - and I mean everything! is a class.

STL was spooking me for a long time. I never used it at Microsoft because things that I worked on - mostly in the core of the OS - had to be insanely fast, and, most importantly, long-running. So I had to care a lot about things like memory fragmentation (see here: http://1-800-magic.blogspot.com/2007/11/guerilla-guide-to-native-memory.html and here: http://1-800-magic.blogspot.com/2007/12/memory-is-not-free-more-on-vista.html).

And it's kinda hard - possible, but you have to bend over backwards - to make STL use custom allocators that were my bread and butter.

Anyway, at Google I had to learn and start using STL. This, unfortunately, made me like C++ (at least STL-ish C++) less and less.

The first problem that jumped at me was the way you learn things. Most of my career I was learning by reading the source.

With C runtime, even with its Microsoft implementation which has way more levels of indirection than necessary, it is easy - you step into the function, and look what's inside. The code that compiler generates maps directly to the source, so the performance is on the surface - it executes as written.

With STL, the file vector - what can be simpler than that?! - is 2424 lines (Visual Studio 2008). algorithm - basically, sorting, searching, and copying - is 5796 lines. This, by the way, is the longest quicksort implementation I've seen in my life :-)! When you step through the code, it's a level of indirection on top of level of indirection on top of level of indirection.

[As a side note - the description of level 62 in old Microsoft - the level where you stop being a junior developer - had, among others, this as a qualification: "Does not create unnecessary abstractions." I think this was written by a smart, smart person!]

Now, consider the following piece of code:

#include <stdio.h>
#include <vector>

using namespace std;

template<class T> class Outer {
  template<class T> class Inner {
  public:
    int i;
    Y t;
    Inner(int a, T b) {
      i = a;
      t = b;
    }
  };

public:
  void DoWork(T t) {
    vector<Inner<T>> data;
    for (int i = 0; i < 10; ++i)
      data.push_back(Inner<T>(i, t));

    for (vector<Inner<T>>::iterator
        it = data.begin(); it != data.end(); ++it)
      it->i += 10;
  }
};

int main(int argc, char **argv) {
  Outer<int> x;
  x.DoWork(25);
  return 0;
}

[Note, this is just an example. The original code was not it. Yes, I know about STL pair.]

This code compiles and runs just fine on Visual Studio compiler. It does not on GCC, for 3 reasons.

First, GCC requires a space between two closing '>' on a templatized template, so you can't write X<Y<Z>>. It has to be X<Y<Z> >.

Second, the template T in the Inner class declaration on GCC shadows the outer T, so it has to be named something else.

And finally, and the most ridiculous - GCC does not parse vector<Inner<T>>::iterator as a type. You have to prefix it with the keyword typename, like so:

  typename vector<Inner<T>>::iterator it =...

If the compiler can't recognize the type as a type, there's something wrong with the code, don't you think?

Update 03/02/2008: Judging from commentrarry, I failed to communicate the intended point. Yes I know that in the three cases above the behavior is required by the standard, and VS2008 is not standards compliant. VS2008 is probably responsible for compiling at least 60% of the code written on this planet, and if the leading compiler is not compliant, this means only one thing - that the standard is too unwieldy. None of this happens to be the case with C or Java - there's only one way to parse them, and they are parsed the same by all tools.

Today, I started looking at the performance of STL code. But this post is getting too big for that, so the details are in the next articles. Here I'll just say that they are not encouraging.