I wrote Effective C++ in 1991. I learned C++ some years before that. When I sat down to write this article, I believed I’d learned C++ in 1986, making 2006 the twentieth anniversary of my learning the language and the fifteenth anniversary of writing a book about it. Alas, memory—or at least my memory—is not to be trusted, and the historical record shows that I really learned C++ in 1988. 2006 thus marks my nineteenth year with C++. While not as round a number as twenty, it still means I’ve been working with the language for a fair chunk of time, and I find that this year, for whatever reason, I’m not just thinking about C++’s future, I’m reflecting on its past. There’s a lot to say about its future, especially with the next version of the language (C++0x) nearing the final stages of specification, TR1 already out, and TR2 ramping up. But right now I want to dwell a bit on what’s already been, and I want to do it in a most audacious way: I want to name my picks for the most important contributions to C++ in various categories...ever.
I’m going to start by naming what I believe to be the five most important books related to C++, but before I do that, I should write a little about me. It goes without saying that my lists of the most important contributions to C++ are subjective and based on my personal experience and perspective. What should probably not go without saying is something about my experience and perspective.
I’ll begin with what many of you will find an unredeemably damning confession: I have not written production software in over 20 years, and I have never written production software in C++. Nope, not ever. Furthermore, I’ve never even tried to write production software in C++, so not only am I not a real C++ developer, I’m not even a wannabe. Counterbalancing this slightly is the fact that I did write research software in C++ during my graduate school years (1985-1993), but even that was small (a few thousand lines) single-developer to-be-thrown-away-quickly stuff. And since striking out as a consultant over a dozen years ago, my C++ programming has been limited to toy “let’s see how this works” (or, sometimes, “let’s see how many compilers this breaks”) programs, typically programs that fit in a single file. (
make? Who needs stinkin’
make?) My living is based on C++, but it’s not by virtue of the programs I write in it.
It’s not by virtue of any intimate association with the language’s standardization, either, because I’ve never been a member of the C++ standardization committee, I’ve never been on the committee’s mailing lists, and I’ve never attended any standardization meetings. My knowledge of the inner workings of the committee—including the things that have had a significant impact on it—is based on what I’ve read and heard from others. This means that I may be ignorant of important forces that shaped C++ as we know it, because those forces may have been felt only within the committee.
Given that I don’t really use C++, nor do I help specify it, you might wonder what I do do. Fundamentally, I study C++ and its application. I gather as much information as I can about the language and its use (from books, magazines, newsgroups, email and face-to-face conversations with developers and members of the standardization committee, experiments with toy programs I write, etc.), organize and analyze what I find, then I package my findings in concentrated form (e.g., books, magazine articles, technical presentations, etc.) for consumption for people like you—people who do use the language. Your job is to employ C++ as a tool to write useful software. My job is to discover and package the information you need to best apply that tool.
I like to think of myself as an outside observer, not too deeply steeped in the day-to-day travails of programmers and not too keenly focused on the minutiae of standardization, yet familiar with both. This series of articles, then, summarizes what this self-proclaimed outside observer thinks have been the most important contributions to C++ since its inception.
By “most important,” I mean the things that have had the greatest impact on developers working in C++. Many of the things on my lists have had a direct impact, i.e., have been felt directly by developers. Widely-used compilers and libraries and widely-read books and articles are examples of things with a direct impact. Things with an indirect impact are those that had a direct or indirect impact (ah, recursion—don’t you love it?) on the things that had a direct impact. For example, you’ll soon see that I name the ISO C++ Standard as one of the most important books ever published, but that’s because of its indirect impact on developers through its direct impact on compiler and library writers.
The importance of some things is quickly apparent. That’s the case with the Standard, for example. More commonly, it takes time to recognize the impact that something has had. That being the case, something relatively new to the C++osphere is less likely to make one of my lists than something that’s been around for a while. On my book list, for example, the most recent entry is from 2001. That doesn’t mean that no important books have been published in the past five years. It just means that from my perspective, nothing that’s been published in the past five years has shown itself to be more important than what’s already on the list. Ask me again in a couple of years, and I may think differently.
To make this list (and all subsequent lists in this series) more meaningful, I’ve decided to impose two constraints on myself. First, I’m really going to limit myself to five books. There will be no spots with more than one book sharing the glory, no honorable mentions for books almost making the cut. Five slots, five books. Second, I’m not going to eliminate my own books from the running. If I’m going to judge others’ books, I should judge mine, too.
Those are fairly severe constraints, so I’ve decided to cut myself slack in one respect: I’m not going to try to order the books on the list (or any of the entries on any of the other lists) from most important to least important. The granularity of my choices is “on the list” or “not on the list.” Within each list, I’ll order things chronologically, in this case by initial publication date.
Here, then, are my picks for the five most important C++ books ever published:
The C++ Programming Language by Bjarne Stroustrup, Addison-Wesley, 1986 (1st edition), 1991 (2nd edition), 1997 (3rd edition), 2000 (special edition). For C++ old-timers, the first edition of this book is the one that started it all—the font of our knowledge. The current edition has swelled to over 1000 pages, including coverage of then non-existent language features like templates, exceptions, and multiple inheritance, not to mention the standard template library, but the first edition—the only edition I’ve actually read cover to cover—was a much more tractable 328 pages. For C++ programmers in the second half of the 1980s, a trip through this book was obligatory, and its influence on the early movers and shakers of C++ is impossible to overestimate. Even now, with a plethora of competing introductory books on C++ available, I recommend that serious developers own a copy of (the current version of) this book, because I consider it the best comprehensive reference on both C++ and how to use it properly.
Stroustrup has been criticized for being too terse in his writing, and I’ve been known to say that if, while reading TC++PL (as it’s often abbreviated), your attention drifts for even a single sentence, you’ll miss something important. (Combine that observation with the 1000+ page length of the current edition, and you’ll being to appreciate why I call this a comprehensive reference.) At the same time, the terseness is part of the book’s quirky charm. For example, this is everything the first edition had to say about handling assignment to self:
if (this == &a) return; // beware of s=s;
In the first edition of Effective C++, I devoted five and half pages to the same potential pitfall. You have to admire a book that can cover it in a half-line comment.
I got lucky with this book; it happened to be the right book at the right time. By 1991, lots of programmers had mastered the basics of the language. They could get C++ programs to do what they wanted, but they felt that they were running into problems they should have been able to avoid. This was one of the first books to focus on using C++ as opposed to simply learning it, and it concentrated on helping developers avoid common pitfalls and make the best use of the language’s non-C features (e.g., constructors and destructors, inheritance, virtual functions, per-class allocators, etc.) Furthermore, it did it in the form of specific guidelines. This was unconventional at the time, as the prevailing approach to discussing C++ was to focus on its flexibility. My experience had been that programmers wanted a way to cope with that flexibility, in essence, to be told what to do. So the book told them. “Always do this.” “Never do that.” A generation of programmers took the advice to heart, as did a number of purveyors of lint-like tools. The Gnu C++ compiler even has an option to enable warnings for constructs that violate guidelines in Effective C++.1 A central feature of the book—one I didn’t grasp until I failed to follow it in my second book (More Effective C++)—was that the Items in the book were short, so they could be read during bus or train commutes, while waiting for meetings to start, or, as I was once told, while going to the bathroom.
Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley, 1995. This isn’t a C++ book per se, but it had a profound influence on the thinking about good design in C++, as well as every other object-oriented programming language. It initiated the patterns movement among professional software developers, and it introduced a set of patterns that remains to this day the core of the common patterns vocabulary. 2 If you’re familiar with the Command, Visitor, Decorator, or Singleton patterns—or with the idea of design patterns at all, you ultimately have this book to thank for it.
The patterns in the book continue to spur active discussion amongst the C++ cognoscenti. For example, Herb Sutter wrote about a new approach to Observer in his September 2003 C/C++ Users Journal column, and Andrei Alexandrescu considered the same pattern in his April and June 2005 C/C++ Users Journal columns.
International Standard for C++, ISO/IEC, 1998 (1st edition), 2003 (2nd edition). Standards documents don’t make riveting reading, but something has to define what is and isn’t C++, and the standard does that. Prior to the standard, the best way to figure out what was valid C++ was to read Margaret Ellis’ and Bjarne Stroustrup’s The Annotated C++ Reference Manual (Addison-Wesley, 1990—commonly known as the ARM), check your code with several compilers, and try to read Bjarne Stroustrup’s mind (possibly using his book as a proxy). The 1998 C++ standard didn’t answer every question (no document can), and it failed to answer some questions its authors thought it did (e.g., must memory for a vector be layout-compatible with a C array?3), but it still represented an enormous unifying force for both implementers and users by serving as the authoritative reference for the language. The 2003 “second edition” was really a bug-fix update, more version 1.1 than 2.0, but still a useful revision of the language’s official specification.
Modern C++ Design by Andrei Alexandrescu, Addison-Wesley, 2001. Templates were really designed to support “containers of T,” but they turned out to be capable of much more. A number of people realized this years before Alexandrescu’s book came out, and, indeed, the STL—part of the 1998 standard—requires implementation techniques far beyond containers of T. But Modern C++ Design was the publication that really blew the template door off its hinges for the C++ community as a whole. So significant was its impact, the current era of C++ programming is named after the book: “modern C++” generally refers to code employing template techniques the book popularized. (Googling newsgroup postings between 1985 and 2000 for “modern C++” yields 662 hits. Googling the same phrase from 2001 to the present yields over 3200 hits.)
It’s unrelated to the importance of the book in C++ history, but it’s worth noting that at the time Alexandrescu published it, he was unable to find a compiler that would accept all the standard-conformant code it contained!
As you review the entries on the list, bear in mind that I’m an Addison-Wesley author, and one of the perks that qualifies me for is getting free copies of pretty much any Addison-Wesley book I want. I’m thus more likely to be familiar with books by Addison-Wesley than by other publishers. Having said that, I’d like to think that if a book by a different publisher had rocked the world of C++, I’d have heard about it.
In the next article in this series, I’ll reveal my choices for the most important non- book publications (e.g., magazine articles, etc.) in the history of C++.
1. The option is
2. From time to time, I google for the most commonly mentioned pattern names on web pages and in Usenet postings, and my results have been consistent over the years: of the 20 most frequently mentioned pattern names, the vast majority are from this book. That’s remarkable for a decade-old book in a very active field.
Information about TR1 (Technical Report 1):
Scott Meyers is the author of Effective C++, the third edition of which was published in 2005. It is available on Amazon.com at:
Scott Meyers is also the author of More Effective C++, which is available on Amazon.com at:
Scott Meyers is also the author of Effective STL, which is available on Amazon.com at:
Scott Meyers’ home page:
Scott Meyers is one of the world's foremost experts on C++ software development. He wrote the best-selling Effective C++ series (Effective C++, More Effective C++, and Effective STL), wrote and designed the innovative Effective C++ CD, is consulting editor for Addison Wesley's Effective Software Development Series, and is a member of the advisory boards for Software Development and The C++ Source magazines. He also sits on technical advisory boards for several start-up companies. A programmer since 1972, he holds an M.S. in Computer Science from Stanford University and a Ph.D. from Brown University.