Top positive review
4 people found this helpful
Not perfect but definitely worth it
on September 4, 2011
Herb Sutter's "Exceptional C++" is the first part of a popular trilogy which has its roots in the "Guru of the Week" newsgroup series. It explicitly assumes that the reader already knows a lot about C++ and is therefore not as pedagogically oriented as Scott Meyers' "Effective C++".
The Good: it's refreshing to see each Item given in quiz format, especially if you've already read 3-4 short-essay C++ advice books (anyone considering "Exceptional C++" should at a minimum first read Meyers' "Effective C++, Third Edition"). Another factor that makes this book pleasant to read is the laid-back writing style. For example, when discussing a confusing piece of code Sutter says in a footnote: "the programmer of Derived ought to be taken out into the back parking lot and yelled at." (Item 21); similarly, when he first introduces the pimpl pointer he adds "//MYOB" (Item 23). Moving on to the themes covered, it should be noted that the book's title is mainly a pun: Sutter includes substantive material on a variety of topics, most notably on containment versus inheritance, the pimpl idiom, and name lookup. At a more fine-grained level, this book contains lots of fascinating tidbits of information. A few examples: a) publicly inheriting from char_traits<char> does not necessarily violate the Liskov Substitution Principle (Item 3), b) private inheritance does not need to keep us from using a derived object polymorphically as a base -- inside the derived object's own member functions and friends (Item 24), c) when calling a function inside a class, if the compiler finds a member it won't bother trying to use Koenig lookup to find free functions (Item 32), d) many of the counter-intuitive aspects of auto_ptr's interplay with change of ownership can be eliminated simply by using const auto_ptr (Item 37) -- of course, in this day and age it's better to avoid auto_ptr altogether, e) comparing pointers into string literals is undefined, so compilers are allowed to store string literals in overlapping areas of memory as a space optimization (Item 38), f) finally, we cannot use static_cast to go from char* to unsigned char* (Item 44). Despite the breadth of the material, there's no denying that one of the finest aspects of this volume is the 10-part miniseries on designing generic containers that are exception-safe (work properly in the presence of exceptions) and exception-neutral (propagate all exceptions to the caller). Regarding the style of the presentation, it's worth noting that certain Items end with a Summary of the lessons learned: this is very helpful when picking up the book months after having finished it. The same goes for many of the guideline boxes that the author has included. Some of these are very good reference material, e.g. the guideline in Item 20 on making an operator a member versus a nonmember function. This box in some senses typifies Sutter's writing: not always easy to read, but well structured and authoritative.
The Bad: in many cases the Item titles are completely uninformative (e.g. "Writing Exception-Safe Code -- Part 7"). On a different note, the writing is often not page-setting aware: Sutter reproduces code or text that we can still see on the facing page (e.g. pp. 4 & 5) or even on the same page (p. 22). The space wasted on duplicating things we can already see might have been dedicated to a few more clarifications (e.g. the return value optimization is mentioned in Items 10 & 46 but is never explained). A similar issue arises when Sutter flat-out repeats material already shown in a previous Item (e.g. Items 31 & 32). A related point is that some of the guideline boxes are too abstract: they tend to generalize the lesson learned and therefore make sense only when you read the entire Item. As a result, different Items sometimes have identical guidelines. This has two unwanted consequences: i) it essentially wastes space that could have been put to better use (as above), and ii) it interferes with skimming, since some of the guidelines are simply too vague to constitute a tangible lesson (e.g. "Know about and use design patterns.", Item 23). In connection to the latter point, let me note that Sutter (or maybe Alexandrescu) did a better job in the "Summary of Summaries" contained in "C++ Coding Standards". At a more detailed level, I also spotted a few more specific (minor) problems: a) in Item 5 the author uses O (that's uppercase O) to denote a template type parameter, a bad practice if ever there was one. b) In Item 23 we read: "you can get fancy and make method a nonclass template parameter instead." However, "nonclass template parameter" is not a C++ term. Perhaps Sutter wanted to say "non-type template parameter" but that wouldn't make sense either, since in the code he shows a type template parameter. c) Item 33 violates Item 23's guideline to prefer the Template Method pattern over public virtual functions. d) Item 44's guideline says "Prefer new-style casts" but Item 5 uses old-style casts. e) Item 43 first recommends const pass-by-value in a function definition and then criticizes a function definition with const pass-by-value by saying that this is "unuseful and misleading at best." f) Finally, in Item 21 Sutter writes: "Some authors even argue that 'void main()' might be standard-conforming. It isn't. It never was, not even in the 1970s, in the original pre-standard C." The problem is, "int main()" wasn't standard-conforming either in those bygone times (nothing was).
Sutter will probably produce a second edition of this book in the not too distant future. Even so, this doesn't mean that the book is out of date: many Items could be re-written in C++11, but most will stand you in good stead for many years to come (a glaring exception being Item 37 on auto_ptr) and would probably help you understand the C++11 simplifications more deeply. Overall, this book is a classic whose author is extremely knowledgeable in all things C++, so it's definitely worth reading. However, despite having been first published more than a decade ago, it does suffer from some presentation issues and minor inconsistencies, which is why I'm giving it 4 stars.