Opinion

---

Last week, in the first article in this series, I identified what I consider to be the most important C++ books, but many important publications about C++ didn’t come in book form. There were also articles in journals, magazines, and on the web; doctoral dissertations and conference proceedings; newsgroups postings; blog entries; standardization documents, etc. They’ve all played a role in the propagation of ideas seminal to the advancement of C++. I haven’t read all of them. I haven’t even read most of them. But as somebody whose job it is to follow C++, I can say that I’ve read a lot of them. This week’s list covers my choices for the five most important non-book publications in the history of C++. As I did when putting together my book list, I limited myself to exactly five publications, I included my own work in the set of candidates (though nothing I wrote was important enough to make the list), and I ordered the list entries by date of publication.

This category forced me to wrestle with a difficult question: if publication A contains an idea that has little direct impact on C++, but the author of publication B reads publication A and includes the idea in publication B, and if B then has wide effect, which publication is more important, A (the “inventor”) or B (the “popularizer”)? I chose B, not because this is inherently correct, but because I didn’t want to try to ferret out from the authors of the following publications whether their ideas were derived from other publications.¹ Instead, I’m taking a page from the C++ language playbook. As you know, const is shallow in const member functions: pointer data members automatically become const, but what they point to doesn’t. In the following list, the publications I cite are, by definition, important, but I assume that the publications on which they are based (and of which I am ignorant) are unimportant. As in C++ itself, this may not be correct behavior, but it’s easy to implement, and it’s therefore what I do.²

Before proceeding to the list, kindly indulge me in a brief elegy for C++ Report, the most significant serial publication ever dedicated to C++. (If you’re not feeling kindly, just skip to the next paragraph.) During most of its years of publication (1989-2000), C++ Report was the paper-based watering hole for the movers and shakers of the C++ world. (The electronic analogue during that period was initially the Usenet newsgroup comp.lang.c++ and later the newsgroups comp.std.c++ and comp.lang.c++.moderated.) Everybody who was anybody published in C++ Report, including names you’ve almost certainly heard of (e.g., all the authors on my “most important C++ books” list) and many more you may not have (e.g., the authors of some of the articles below, as well as....the list is too long to even start. I know, because I started it, and after a few names, I realized I would either have to include dozens or risk implying that omitted names were less important than included ones. Rather than do that, I’ll list none, but trust me, in its heyday—which was most of its life—C++ Report attracted the best authors in the business: the ones with the most interesting things to say and the greatest ability to say it.) When C++ Report closed shop, many of its columnists moved to C/C++ Users Journal, but that magazine never held the magic for me that C++ Report did, and now that CUJ is gone, there’s nothing left of C++ Report except prattling old codgers like me bemoaning the passage of time.

Okay, I feel better now, so let’s move on to my list of the five most important non- book C++ publications...ever:

• Programming in C++, Rules and Recommendations by Mats Henricson and Erik Nyquist, Ellemtel Telecommunication Systems Laboratories, 1992. I mentioned in my previous article in this series that by the early 1990s, many programmers were looking for guidance on how to harness the power of C++, and they were often interested in coding guidelines that would tell them what to do and what to avoid doing. At about the same time I tried to offer such guidance in Effective C++, Mats Henricson and Erik Nyquist published their programming guidelines on the internet. In fact, their guidelines had already been available for some time, but they had been in Swedish, which had rather limited their appeal.

  The Ellemtel guidelines were technically sound and easy to read, and they became both popular and influential. It soon became known that they were to be made available in book form, a development which filled me with some foreboding. (Competition may be good for the market, but at the time, I was pretty much the only player in the market, and I liked it that way.³) We kept expecting the book and expecting the book and expecting the book, and years went by. It finally came out at the end of 1996 (Industrial Strength C++ by Mats Henricson and Erik Nyquist, Prentice Hall, 1997), but by then, many of its guidelines were out of date with respect to contemporary compilers, and much of the information it contained had become so well known in the C++ community, it was perceived to be less useful than it had been four years earlier when the guidelines first appeared in English. I read the book, first with interest, then with some sadness, because I felt that during the four-year transition from internet document to book, not only had the technical information lost some of its edge, the writing itself had lost its soul. My guess is that the manuscript may have entered endless rounds of reviews with a goal being to achieve consensus with reviewers on everything. That would explain why it took so long to be published as well as why the resulting writing was so much blander.

  The book made a smaller splash than I suspect its authors (and publisher) hoped, but that doesn’t diminish the impact of the original internet document. When it came out, C++ programmers ate it up. It was an important step in the codification of C++ best practices.

• “Exception Handling: A False Sense of Security” by Tom Cargill, C++ Report, November-December 1994. In 1994, there was a strong sense of smugness in the C++ community. C++ was the hot programming language, jobs were plentiful, and there was a feeling of limitless possibilities. Within the prior few years, the language had added a number of important new language features, including multiple inheritance, templates, and most recently, exceptions. Because exceptions were new, articles describing them appeared regularly in C++ Report and wherever else C++ programmers gathered to talk shop. Most articles reflected the smugness of the age: “Exceptions are wonderful. They make handling error conditions simple. All you have to understand is try, throw, and catch. Here, watch me develop a stack class and demonstrate how exceptions make coding in C++ better than ever.” Tom Cargill’s article (actually an instance of his recurring column, “C++ Gadfly”—certainly one of the most aptly named columns ever created) obliterated the self-satisfied smile from our collective faces. In a single sentence, Cargill explained that try, throw, and catch had nothing to do with the matter:

  The really hard part of using exceptions is to write all the intervening code [between the throw and the catch] in such a way that an arbitrary exception can propagate from its throw site to its handler, arriving safely and without damaging other parts of the program along the way.

  The column went on to vivisect a previous C++ Report column of the “exceptions are wonderful” variety I described above,⁴ and it ended with a challenge (Cargill called it an “invitation”): to publish an exception-safe stack class. That challenge led to a flurry of responses, but, in my opinion, the challenge was not really met until an article by Herb Sutter in 1997 (see below).

  Tom Cargill’s column not only demonstrated that our thinking about exceptions was naïve, I think it also marked an end of innocence for C++. By the time we’d figured out how to write exception-safe code, Java was the new darling programming language (it’s now Ruby on Rails from what I can tell), and the unquestioned “we’re number one!” mentality has never really returned.

• “Curiously Recurring Template Patterns,” by Jim Coplien, C++ Report, February 1995. The significance of this article lies not in what it described, but in the fact that it gave it a name. This is doubly ironic, because the article was an instance of Coplien’s column, “The Column Without a Name,” and the name he assigned has got to be the strangest one in the patternverse: The Curiously Recurring Template Pattern (CRTP).⁵ The pattern itself is the use of a derived class as the parameter to its own templatized base class:

  template<typename T>
  class Base { ... };
  
  class Derived: public Base<Derived>
  { ... };
  

  Most people whose template usage strays beyond containers of T eventually come up with a design that incorporates the CRTP, and when they do, it’s common for them to doubt that it will compile, and, when they discover (possibly to their horror) that it will, worry that their design is a symptom of early-onset dementia. That’s when Coplien’s contribution kicks in. More experienced colleagues can offer reassurance: “No, you’re not insane. Having a derived class inherit from a base class templatized on the derived class can not only be a legitimate design technique, it’s even got a name: the Curiously Recurring Template Pattern.”

• “Using C++ Template Metaprograms” by Todd Veldhuizen, C++ Report, May 1995. This article represented the first large-scale public appearance of template metaprogramming (TMP). It was a momentous occasion, and I completely missed the boat. I remember reading the article and thinking, “Okay, so you can use recursively instantiated templates to simulate for loops during compilation. And you can use template specialization to implement compile-time switch statements. That’s nice, but why would you want to?” Actually, I’m lying. What I really thought was, “But you’d have to be a lunatic to want to.”⁶

  That there was no shortage of lunatics in the C++ community failed to surprise me, nor did the fact that further articles on TMP continued to appear in various fora, but I honestly thought that TMP was a technology too conceptually bizarre and syntactically foreboding to have any legs. It’s now clear that it’s got legs aplenty, though I take some solace in the knowledge that most people seem to agree that it is syntactically intimidating and, if not conceptually bizarre, it’s at least well out of the mainstream. Still, it’s a critical tool in every library developer’s bag of tricks. As penance for so seriously underestimating its significance when Veldhuizen first wrote about it, I did my best to summarize the technology and its uses in an Item in the third edition of Effective C++.

• “Exception-Safety in Generic Components” by David Abrahams. The earliest publication date I can find for this is the Proceedings of the International Seminar on Generic Programming, Dagstuhl Castle, Germany, April 27 - May 1, 1998, but the material must have been available by mid-1997, because Herb Sutter referred to material in David Abrahams’ paper in an article in the September 1997 issue of—where else?—C++ Report. I also found reference to this material in an April 1997 Usenet posting by David Abrahams (http://tinyurl.com/nk5vn), but, unfortunately, the link included in that article no longer works.

  These days, the three possible exception-safety guarantees a function can offer—basic, strong, or nothrow—are well known. Herb Sutter popularized these terms and has written extensively about them, but the document that introduced them came from David Abrahams and, to be honest, the primary reason I know that is that Sutter has been careful to acknowledge that fact.⁷ This is a case, I think, where an important document had a fairly narrow initial circulation, but among the people who read it were many in positions of significant influence (e.g., were defining the standard for C++ and/or were responsible for implementations of the standard library), so the effect of the document was greatly enhanced.

  Interestingly, though Abrahams’ document was instrumental in establishing the understanding of exception safety that underlies the specification of the C++ standard library, there is no mention in the C++ standard of the “basic guarantee,” “strong guarantee,” or “nothrow guarantee.”

This list and the one before it dealt with publications about C++, but C++ itself is about software, so in my next episode in this series, I’ll identify the five most important pieces of C++-related software that have ever been.

End Notes

1. The problem is really worse than that, because of the transitive closure issue (i.e., B got the idea from A, but A got the idea from Z, and Z got the idea from Y...).

2. The reason for const being shallow probably has nothing to do with ease of implementation. Rather, it’s a natural fallout of the usual rules regarding const and pointers. If a pointer p is const, it’s not necessarily the case that *p is. In the case of a const member function, *this is const, but if p is a pointer member of *this, that says nothing about whether *p is also const.

3. There was another, slightly earlier, C++ guidelines book, Thomas Plum’s and Dan Saks’ C++ Programming Guidelines, Plum Hall, 1991, but it never gained a lot of traction. It’s been a long time since I really looked at it, but my recollection, based on a very quick read now, is that it was, um, dull.

4. I was a C++ Report columnist at the time, and I remember thinking that Cargill could just as easily have trained his sights on me, had I chosen to write about exceptions. Watching him methodically—but completely professionally—expose the shortcomings of a colleague’s work was one of the most wrenching things I have ever experienced. I’m sure I’m not the only columnist who from that day forward triple-checked his work before publication.

5. Andrei Alexandrescu, now working on his Ph.D. in Computer Science, has been known to argue that the pattern should be recognized as what it is, a simple example of F-bounded polymorphism, but he has had no luck in getting people to heed this suggestion. This pleases me, because I have a Ph.D. in Computer Science, and I’d never heard of F-bounded polymorphism. “CRTP” is an odd name, but it still strikes me as less intimidating than F-bounded anything.

6. It probably didn’t help that the article implemented a compile-time bubble sort as its first example. I have a pathological aversion to bubble sort. Not only is it almost never the right sort algorithm for the job, it’s almost never even worth considering for the job. But I digress.

7. When this started is not entirely clear. The printed version of Sutter’s September 1997 C++ Report article mentions the basic and strong guarantees without attributing them to Abrahams, but the version of the article he permitted me to include on my 1999 Effective C++ CD does refer to Abrahams. I have enough experience with publishing to know that what got printed by C++ Report is not necessarily the same as what Sutter submitted.

Resources

Part I in this series, “The Most Important C++ Books...Ever”:
http://www.artima.com/cppsource/top_cpp_books.html

Programming in C++, Rules and Recommendations by Mats Henricson and Erik Nyquist:
http://www.doc.ic.ac.uk/lab/cplus/c++.rules/

“Exception Handling: A False Sense of Security” by Tom Cargill, C++ Report, November-December 1994:
http://www.awprofessional.com/content/images/020163371x/supplements/Exception_Handling_Article.html

“Using C++ Template Metaprograms” by Todd Veldhuizen, C++ Report, May 1995:
http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html

“Exception-Safety in Generic Components” by David Abrahams:
http://www.boost.org/more/generic_exception_safety.html

Scott Meyers is the author of Effective C++, the third edition of which was published in 2005. It is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/0321334876/

Scott Meyers is also the author of More Effective C++, which is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/020163371X/

Scott Meyers is also the author of Effective STL, which is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/0201749629/

Scott Meyers’ home page:
http://www.aristeia.com/

Talk back!

Have an opinion? Readers have already posted 6 comments about this article. Why not add yours?

About the author

Scott Meyers is one of the world’s foremost authorities on C++; he provides training and consulting services to clients worldwide. He wrote the best-selling Effective C++ series (Effective C++, More Effective C++, and Effective STL), designed the innovative Effective C++ CD, is Consulting Editor for Addison Wesley’s Effective Software Development Series, and serves on the Advisory Board for The C++ Source (http://www.artima.com/cppsource/). He has a Ph.D in Computer Science from Brown University. His web site is aristeia.com.