Lately I've been doing a lot of work with the C++ STL (Standard Template Library) in my own programming projects. For the most part, STL seems to be as nifty as it's cracked up to be. It has dramatically simplified many of my programming tasks. In fact, there are projects I would not have even attempted were it not for the existence of STL.
To this glowing endorsement I must add a caveat: using STL is 90% joy, 10% sheer frustration. The frustration comes from the 'T' in STL, as in template <class T>. Debugging templatized code, especially the kind found in STL applications, is anything but straightforward. Gone are the days when a successful compile to line 100 meant lines 1-99 were error free. Today's compiler may well revisit portions of templatized code and flag statements you thought had already checked out. Template error messages are at once verbose and uninformative. The typical compiler diagnostic is like the howling of a newborn baby. It can tell you something's wrong, but it can't tell you what. I expect that as compilers get better, they'll become more articulate about template problems. For now, figuring out what the compiler doesn't like involves too much guesswork for my taste.
I don't want to give the wrong impression. You can do a lot of things with STL without knowing much about templates. But when you try to write code that is truly portable and general-purpose, a host of subtle questions arise as to what a compiler can be reasonably expected to do. Good luck finding the answers in books and magazines. Most authors, it seems, want only to write about the mathematical beauty of STL. Which is fine, as far as it goes, but it misses the mark. Programmers today also need compiler-specific information, tips, and workarounds.
So I'm once again turning this column into an ad hoc Call for Papers. Send me your discoveries, tips, and questions about using templates and STL with a real compiler in a real-world environment. I won't be able to answer your questions, but I'm sure I can find a guru who can. If I get enough tips, I'll turn them into a new CUJ department. Send your tips to mbriand@mfi.com.
On another subject, you'll notice that Dan Saks' column is missing from this issue. Dan has asked for a three-month ''sabbatical,'' to use his terminology, and he certainly deserves it. Dan has been writing for CUJ for the past eight years, rarely missing an issue. Knowing Dan, he's not just sitting around. When he comes back, I'm sure he'll have more deep insights into this sometimes frustrating, always interesting thing we call C++.
Marc Briand
Editor-in-Chief