STL, language lawyers and pedantry

Any­one who’s been around a C++ pro­gram­mer for any length of time has prob­a­bly real­ized that we tend to be hor­ri­ble lan­guage lawyers: we only trust the ISO stan­dard describ­ing the lan­guage. We cer­tainly would never assume some­thing to work just because the com­piler hap­pens to gen­er­ate code that works right now. If it’s not in the stan­dard, we can’t count on it.

I’m fine with that. It’s often annoy­ing that we have to be so para­noid, that we so often have to double-check that our code not only com­piles, not only passes our tests, but also avoids the dreaded Unde­fined Behav­ior (where the behav­ior is not con­strained by the stan­dard), but you get used to it. And all in all, being pre­cise and spe­cific when talk­ing to a com­piler is prob­a­bly not a bad habit to get into, regard­less of which lan­guage you pro­gram in.

How­ever, every once in a while, peo­ple try to carry the same level of pedantry over into dis­cus­sions about C++. In par­tic­u­lar, a cer­tain sub­set of C++ experts reg­u­larly com­plain that nearly every C++ pro­gram­mer has their ter­mi­nol­ogy mixed up. And that annoys me. If 99.9% of all C++ pro­gram­mers use a term in one spe­cific way, then even if it’s not sup­ported by the ISO stan­dard, per­haps we should just accept it. Yes, if you’re a com­piler, it would intro­duce an ambi­gu­ity, but we’re not. We’re human beings, and we’re good at deal­ing with ambi­gu­i­ties. And while using the term cor­rectly would the­o­ret­i­cally elim­i­nate any ambi­gu­ity, in prac­tice it would cause a lot of it instead: today, we can guess with 99.9% cer­tainty that peo­ple use the “incor­rect” def­i­n­i­tion when they use the term. If we tried to make every­one use the term cor­rectly, we’d be unable to guess at which mean­ing peo­ple actu­ally intend to use.

The term in ques­tion is, of course, the STL. The Stan­dard Tem­plate Library, devel­oped by Stepanov in 1994, made avail­able by SGI and finally adopted with some changes and some parts left out by the C++ stan­dards com­mit­tee into the C++ lan­guage in 1998.

Strictly speak­ing, the name “STL” refers to the SGI library (and, some would argue, to the language-agnostic idea for a library grad­u­ally devel­oped by Stepanov before he imple­mented it in C++). Strictly speak­ing, the C++ stan­dard makes no men­tion of a “Stan­dard Tem­plate Library”. Strictly speak­ing, “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++ stan­dard library. Strictly speak­ing, no one would ever want to use the name “STL” today.

And yet even C++ experts like Scott Mey­ers and Herb Sut­ter use the term incor­rectly (unless we accept that Sut­ter offers courses in a 15-year old obso­lete library rather than effec­tive use of the C++ stan­dard library)

And of course, the best part is that if we all were to start using the term cor­rectly, we have noth­ing to replace it with. We don’t have another name for “the STL-derived parts of the C++ stan­dard library”. We can say “the C++ stan­dard library”, which, apart from being an extremely ver­bose name, also cov­ers all the other parts of the stan­dard library.

So really, is it worth it? What pur­pose does it serve to try to con­vince every C++ pro­gram­mer in the world, to stop using the name “STL” to describe “the parts of the C++ stan­dard library which look sus­pi­ciously like the STL”? We free up the name so we can use it to name a library that we vir­tu­ally never need to men­tion. And we get to be won­der­fully pedan­tic when talk­ing about the C++ lan­guage, just like we already are when talk­ing about C++ code. But we’ll also cause a lot of con­fu­sion, mak­ing it need­lessly dif­fi­cult to dis­cuss one of the most com­monly dis­cussed areas of C++, because 1. it no longer has a sim­ple name, and 2. when peo­ple use that name, we no longer have any idea what they’re refer­ring to. They could be a “reformed” well-behaved C++ pro­gram­mer, using it to refer, for some rea­son, to a library no one has used for the past 10 years, or they could be a rebel­lious trou­ble­maker abus­ing the name to refer to a sub­set of the C++ stan­dard library.

So, an appeal to all those C++ experts who think the world would be a bet­ter place if we all used the name STL cor­rectly: stop it. Sit down, take a deep breath and accept and assume that the name is going to be used incor­rectly by vir­tu­ally every­one vir­tu­ally all the time. Don’t pre­tend to be con­fused when peo­ple say “STL”, because you’re not. The ambi­gu­ity exists only on a the­o­ret­i­cal level. In prac­tice, no one ever wants to talk about the SGI library, and if they do, they will make it clear from context.

Share and Enjoy: These icons link to social book­mark­ing sites where read­ers can share and dis­cover new web pages.
  • Digg
  • StumbleUpon
  • Reddit
  • Technorati

Tags: ,

4 Responses to STL, language lawyers and pedantry

  1. None says:

    The issue is one of con­fu­sion. Which parts of the stdlib are in the STL? iostream? string? slist and oth­ers in the SGI STL, pro­vided by some imple­men­ta­tions, but not in the stan­dard? Addi­tions from TR1? What about 0x? Even though most peo­ple have very sim­i­lar def­i­n­i­tions, they are all slightly off from each other.

    Why not just say “stdlib” if you mean the C++ Stan­dard Library?

    How­ever, I some­times do want to talk about the SGI library — or rather the ideas and idioms it made pop­u­lar in C++, even if not the actual source code.

  2. whoiscraig says:

    I actu­ally read this!

  3. […] — [1] “When the STL Isn’t Enough: Adding Perl to Your C++ Appli­ca­tions”, Ken Fox, 1998 [2] C++ as defined by ISO/IEC 14882 – 1998 & ISO/IEC 14882 – 2003. [3] “STL, lan­guage lawyers and pedantry”, Jes­per Alf Dam, 2010 […]

  4. Nawaz says:

    I liked this post. And com­pletely agree with the thought and the last para­graph. I would also like to repeat : “Don’t pre­tend to be con­fused when peo­ple say “STL”, because you’re not.” Haha.

Leave a Reply

Name and Email Address are required fields. Your email will not be published or shared with third parties.