Ever try to change a bike tire with a screwdriver, or loosen a nut with a pipe-wrench? Well I have, and let me tell you, it wasn't pretty. I now understand why using "the right tool for the job" is so important. In software development, though, correct usage can be a pretty murky issue. It is impossible to predict all the ways programmers will use a tool, or all the consequences.
Consider the unusual technique known as template metaprogramming (or TM, for short). TM is a way of hijacking the template-handling smarts of a compiler to perform calculations at compile time. In the process of expanding templates, the compiler appears to be "executing" code — and in a way, it is. For an example of TM, take a look at the article by Zlatko Marcok, "Dynamic Arrays with Expression Templates," in this issue. Marcok shows us that, weird as they are, template metaprograms can yield some truly elegant solutions. Zlatko's templates make it criminally easy to create dynamic arrays. In this respect, TM seems like a great tool. But let's bump the clock forward a few years and ask the maintenance programmers what they think of TM. Chances are we couldn't print all their comments in this magazine.
If the TM code breaks, the maintenance programmers will be wading through source statements such as: Expr<ToupleExpr< Expr<ToupleExpr<Dim,Dim>, 2 >, Dim >, 3 > I don't know about you, but I find this code a bit mind bending. TM may add undue complexity in some situations.
Which is not to knock Zlatko's article. It's an elegant piece of work in itself, and we're happy to run it as a new solution for an old and troublesome problem. But when using a new software tool, we should ask whether we're really simplifying things or trading off one form of complexity for another. If it is a tradeoff, it should be made consciously.
Elsewhere in this issue, Dan Saks questions whether namespaces make an effective abstraction tool. Namespaces were not originally conceived as such. They were designed to prevent global namespace conflicts. But abstraction is touted, like TM with templates, as a lucky side-benefit of namespaces. Maybe it shouldn't be. I leave it to Dan to tell you why. Of course, Dan would never claim omniscience with respect to namespaces. They are so new no one has figured out all their (ab)uses. But "new" translates to "cool," and cool too often translates to unwise use. I think Dan would like to spare you that, and so would I.
Speaking of abuse, we've recently sent Bobby Schmidt packing into uncharted territory without compass or compiler. That territory is C9X, the next proposed standard for C. Bobby has begun investigating VLAs (Variable Length Arrays), a new sort of dynamic array you won't find in Standard C.
On the surface, VLAs look like a godsend, a badly needed tool for C. But there is a dark side. Taking a cue from C++, VLAs are WYSINAYG (What You See is Not All You Get). They could incur hidden run-time costs. Unfortunately, it will be years before we know what VLAs are really like.
I'm hardly one to scold readers for misusing a tool. I've done it too often with hardware tools, and gotten away with it to boot. I suspect, though, that some of our new software tools will not be so forgiving. It really gives me an appreciation for analysis and planning. Now if I can just find that darn slide rule...
Marc Briand
Editor-in-Chief