I’m fine with that. It’s often annoying that we have to be so paranoid, that we so often have to double-check that our code not only compiles, not only passes our tests, but also avoids the dreaded Undefined Behavior (where the behavior is not constrained by the standard), but you get used to it. And all in all, being precise and specific when talking to a compiler is probably not a bad habit to get into, regardless of which language you program in.

However, every once in a while, people try to carry the same level of pedantry over into discussions about C++. In particular, a certain subset of C++ experts regularly complain that nearly every C++ programmer has their terminology mixed up. And that annoys me. If 99.9% of all C++ programmers use a term in one specific way, then even if it’s not supported by the ISO standard, perhaps we should just accept it. Yes, if you’re a compiler, it would introduce an ambiguity, but we’re not. We’re human beings, and we’re good at dealing with ambiguities. And while using the term correctly would theoretically eliminate any ambiguity, in practice it would cause a lot of it instead: today, we can guess with 99.9% certainty that people use the “incorrect” definition when they use the term. If we tried to make everyone use the term correctly, we’d be unable to guess at which meaning people actually intend to use.

The term in question is, of course, the STL. The Standard Template Library, developed by Stepanov in 1994, made available by SGI and finally adopted with some changes and some parts left out by the C++ standards committee into the C++ language in 1998.

Strictly speaking, the name “STL” refers to the SGI library (and, some would argue, to the language-agnostic idea for a library gradually developed by Stepanov before he implemented it in C++). Strictly speaking, the C++ standard makes no mention of a “Standard Template Library”. Strictly speaking, “STL” refers to a 15 year old library that no one would ever dream of using, because we’ve got an up-to-date near-copy in the C++ standard library. Strictly speaking, no one would ever want to use the name “STL” today.

And yet even C++ experts like Scott Meyers and Herb Sutter use the term incorrectly (unless we accept that Sutter offers courses in a 15-year old obsolete library rather than effective use of the C++ standard library)

And of course, the best part is that if we all were to start using the term correctly, we have nothing to replace it with. We don’t have another name for “the STL-derived parts of the C++ standard library”. We can say “the C++ standard library”, which, apart from being an extremely verbose name, also covers all the other parts of the standard library.

So really, is it worth it? What purpose does it serve to try to convince every C++ programmer in the world, to stop using the name “STL” to describe “the parts of the C++ standard library which look suspiciously like the STL”? We free up the name so we can use it to name a library that we virtually never need to mention. And we get to be wonderfully pedantic when talking about the C++ language, just like we already are when talking about C++ code. But we’ll also cause a lot of confusion, making it needlessly difficult to discuss one of the most commonly discussed areas of C++, because 1. it no longer has a simple name, and 2. when people use that name, we no longer have any idea what they’re referring to. They could be a “reformed” well-behaved C++ programmer, using it to refer, for some reason, to a library no one has used for the past 10 years, or they could be a rebellious troublemaker abusing the name to refer to a subset of the C++ standard library.

So, an appeal to all those C++ experts who think the world would be a better place if we all used the name STL correctly: stop it. Sit down, take a deep breath and accept and assume that the name is going to be used incorrectly by virtually everyone virtually all the time. Don’t pretend to be confused when people say “STL”, because you’re not. The ambiguity exists only on a theoretical level. In practice, no one ever wants to talk about the SGI library, and if they do, they will make it clear from context.

But I’m still not sure what I want to write about. I’ve got a few ideas, mainly by asking some of the professors I might want as advisors if they had any interesting projects lying around.

So far, this is what I have:

1. Efficient inversion of huge block-diagonal matrices on a CELL processor
2. Multi-threaded implementation of the C++ STL
3. writing a GPU shader language, probably in a more functional style than existing languages, taking advantage of the inherently side-effects-free platform

The first one is based on a project I did last year. It was fun, and there’s still plenty left to do. The algorithm may sound dull (matrix inversion?), but the fun part is implementing it on a CELL, and the algorithm has a lot of steps that are challenging to implement efficiently on the hardware. Working with a CELL is interesting, and since I’ve done it before, I can get started relatively quickly, sidestepping all the beginners’ trouble figuring out how to program the monster. So that’s definitely an option. On the downside, it’s, well, stuff I’ve done before, more or less.

The second sounds like a blast, to be honest. It could be a lot of fun. Unlike the CELL project, I wouldn’t have to worry about weird hardware limitations, but can instead focus on crazy C++ templates and generic programming. I still have to figure out a specific angle on it though. Simply implementing multithreaded versions of the functions in the algorithm header is obvious, but has been done already. Implementing the containers with multithreading in mind might be interesting, but then the problem is no longer that of automatically parallelizing code (which is fun), but rather that of ensuring our code is thread-safe (which is… less fun). A third option might be to use such a parallel STL implementation to solve some problem.

The third one is a pet project I got the idea for a year or so ago. I’m still not sure about it. I think the basic idea is good, and it could be fun, (and would be relevant if I want to get into the games industry after I graduate) but there are a lot of unknowns involved:

• I’m not exactly a hardcore compiler writer. I’ve taken both the basic and advanced compiler courses at uni, and passed them with good grades and without too much trouble, but all the more theoretical courses about partial evaluation, big-step semantics and other fancy theory just leave me cold. I doubt any of that will be necessary, but.… is it a risk I want to take on my thesis?
• GPUs have a lot of unusual hardware characteristics I’ll have to deal with — first of course, that they are inherently SIMD instruction sets, second that there is very little support for branch/jump instructions, a fixed number of registers and no memory you can spill into. Writing a compiler for that seems
• It’ll most likely have to target one of the existing shader languages (Cg, GLSL, HLSL). Is that practical? How should it interface with OpenGL/Direct3D, if it were to be useful in practice?
• It seems like a lot of work…

So yeah, the last one has a certain attraction in that it’s my idea, where the others are suggestions I’ve been given, but it’s also scary as hell. And like I said, the two first suggestions are great fun too.

What to do? I’ll have to decide in a couple of days. I don’t want to wait any longer before starting on it.