I was recently informed that the German translation of Effective C++ will be reissued with a new cover as part of their "classics" series. They asked me to write a little something about it, and I came up with a new preface that considers the relevance of the information in the book in the age of C++0x/C++11. Given the adoption of the FDIS, plus the fact that the preface will be published only in translation, it seems appropriate to post it here:
2011 is an exciting year for C++ developers. It marks the official debut of the new standard for C++, informally known as “C++0x”. Over a dozen years in the making, C++0x makes C++ more powerful and flexible than ever. In addition to introducing major new features, such as support for concurrency, lambda expressions, move semantics, and type deduction for variables (auto variables), C++0x provides an assortment of secondary capabilities that also increase expressiveness, improve efficiency, and eliminate programming drudgework. Examples include range-based for loops, static assertions, inheriting and delegating constructors, reference-counting smart pointers, hash tables, regular expressions, variadic templates, and more. All told, the C++0x feature set is about twice that of “old” C++. Furthermore, the feature set is increasingly real: the number of C++0x features supported by modern compilers is large and growing quickly. 2011 isn't just the year when C++0x receives official ratification as a new standard, it's also the year in which it starts to see serious mainstream use.
Which may lead you to wonder whether the information and advice in this pre-C++0x edition of Effective C++ remains relevant. I'm pleased to report that it does. Surprisingly so, in fact. Having spent nearly two years steeped in the details of C++0x, I expected to groan a bit as I reviewed this book's table of contents with C++0x in mind. Surely some Items would be inappropriate. But the advice I found proved sound. Should C++0x developers prefer consts, enums, and inlines to #defines (Item 2)? They should. Should they prevent exceptions from leaving destructors (Item 8)? Certainly. Should they use objects to manage resources? Declare data members private? Consider alternatives to virtual functions? Factor parameter-independent code out of templates? (Items 13, 22, 35, and 44.) Yes, yes, yes, yes! My goal has always been for Effective C++'s table of contents to summarize the advice in the book, and that summary remains just as applicable to C++0x development as to “traditional” C++ development. C++0x is a bigger language, and in some ways it's a different one, but the core techniques for making effective use of “old” C++ are core for the effective use of C++0x, too.
This doesn't mean that this Effective C++ is a perfect match for C++0x. The book doesn't discuss features new to C++0x, so Items about making effective use of those features are missing. A C++0xified Effective C++ would certainly have Items devoted to move operations, to uniform initialization, and to lambda expressions, and it'd probably have an entire chapter on making effective use of the concurrency API. Such a book would also contain different examples, e.g., ones making use of auto variables, range-based for loops, in-class default initializers, as well as the occasional variadic template. To the extent that this book falls short in its support for C++0x, the errors are those of omission, not commission.
But Effective C++ has never claimed to be a comprehensive book. My intent has never been for it to address every aspect of the language. Rather, it has been to examine the most important aspects of C++ that affect practicing programmers on a day-to-day basis. C++0x introduces new aspects of the language that warrant discussion, but that doesn't diminish the importance of the issues I treat in this book. In fact, it may accentuate them, because effectiveness with C++0x requires mastery of the language it extends, i.e, “old” C++. As the shiny new parts of C++0x garner more and more attention, discussion of the “old” parts will recede, but those parts will still be important.
Whether you're programming in “traditional” C++, “new” C++, or some combination of the two, then, the information and advice in this book should serve you well, both now and in the future.
