 |
|
| Title: | Exceptional C++: 47 Engineering Puzzles, Programming Problems, and Solutions |
| Author: | Herb Sutter |
| Publisher: | Addison-Wesley, 2000 |
| Pages: | 208 |
| ISBN: | 0201615622 |
| Price: | $33.95 |
Exceptional C++ by Herb Sutter is a volume in Bjarne Stroustrup's C++ In-Depth Series published by Addison-Wesley. It provides 47 items divided into eight categories, including Generic Programming, Exception Safety, Class Design and Inheritance, Memory Management, and the infamous Miscellaneous Topics. Each item is presented in the form of a coding or design problem followed by a discussion of its solution. The items are primarily reworked and expanded versions of Herb's (Guru of the Week), which Herb regularly posts on comp.lang.c++.moderated. Many of the items form a multipart sequence, a kind of theme and variation that provide a multifaceted look at the initial problem. The book's treatment of exception safety alone makes it an invaluable addition to every C++ programmer's bookshelf.
In general, each item presents a programming or design problem, usually coupled with one or more philosophical asides. For example, item 2 requires us to
Write a ci_string class that is identical to the std::string class but that is case-insensitive in the same way as the commonly provided extension stricmp(). A ci_string should be usable as follows...
and gives us a series of uses of the class that our implementation needs to support. To put the solution in context, he adds two questions to the problem:
- What does "case insensitive" mean?
- Is making case sensitivity a property of the object a good idea?
The point of the first question is to underscore that our solution is context sensitive — that is, if we would like a solution that can be applied to languages other than English. The second question raises the interesting issue of whether the case sensitivity should be contained within the implementation of the class or be a characteristic of the comparison operator.
The actual solution to the problem is both quite ingenious and rather obvious. Or rather, it is obvious once one understands the solution. Rather than re-implement the standard library string class, a different character trait is derived and passed to the existing class! It didn't even occur to me, although it's an obvious and quite wonderful solution.
Prior to this material, the best treatment of traits that I am aware of is the C++ Report article, "A New and Useful Template Technique: 'Traits'" by Nathan Myers. In it, Nathan explains the motivation behind its introduction in the standard library and illustrates its implementation. There is an enthusiasm in Nathan's article that is quite wonderful. A similar zest often informs Herb's writing. Items 2 and 3 provide an excellent addition to the treatment of traits.
The core of the book is a 10-sequence treatment of exception safety. Back in 1994, Thomas Cargill, as the C++ Gadfly columnist for the C++ Report, wrote an article in which he pointed out in a column a number of exception-unsafe conditions of a Stack template class that neither the author (nor myself as editor) had recognized. Tom began his article as follows,
I suspect that most members of the C++ community vastly underestimate the skills needed to program with exceptions and therefore underestimate the true cost of their use. The popular belief is that exceptions provide a straightforward mechanism for adding reliable error handling to our programs. On the contrary, I see exceptions as a mechanism that may cause more ills than it cures. Without extraordinary care, the addition of exceptions to most software is likely to diminish overall reliability and impede the software development process.
Tom concludes his article with the following challenge to the C++ community with regard programming in an exception-safe manner:
Although I can see how to correct many of the faults in Stack [the example class is a Stack], I am not confident that I can produce an exception-correct version. Quite simply, I don't think that I understand all the exception-related interactions against which [the class implementation] must defend itself. Rather, I ... encourage others to think exhaustively about the issues and perhaps uncover situations that I have missed.
This 10-item sequence, which iteratively walks through the implementation of a Stack, provides the most exhaustive treatment of programming exception-safe C++ that I am aware of — Jack Reeves has also done good work responding to Cargill's challenge in a series of articles a few years back in the C++ Report. I don't see how a project attempting to program in the presence of exceptions can proceed without at least being familiar with this material.
Probably the hardest area of C++ to write about without become either tedious or arcane is that of name lookup. The four-item sequence, "Name Lookup, Namespaces & the Interface Principle," does a remarkably good job of walking us through the minefield of name resolution rules in Standard C++.
There are parts of the text I take exception to, of course. "The Interface Principle," for example, is over generalized. A literal application of this principle, for example, results in treating every non-member function that takes a vector parameter as being considered logically part of the vector class and to form part of the vector interface. While that may be true in a broad sense, it is too broad to be helpful.
Other issues are primarily matters of opinion. For example, I have always felt embarrassed by the standard library auto_ptr class. The book chooses to celebrate it, although it adds, "But beware: Never use auto_ptrs except in one of the ways I've just described. I have seen many programmers try to use auto_ptrs in other ways...." Etc. and so on.
These are minor criticisms for what is otherwise a major achievement. Exceptional C++ is not a book for the beginning C++ programmer, however. Rather, it is for the working programmer looking for ways to use C++ more effectively (and who among us isn't?) — in particular, the Standard C++ language features and libraries. It's interesting to interpolate the author's own assessment of the book's difficulty. Each item comes ranked with a difficulty ranking, from 1 to 10. The math is revealing: The book's average difficulty level as rated by the author is 6.4! 44.6 percent of the book is rated at a difficulty level of 7 or above. In fact, the "easy" items tend to be statements of principle rather than actual problems (for example, see item 25, "Object-Oriented Programming (4)" or item 35, "Memory Management, Part 1 (3)"). I can't imagine anyone reading this book and not learning something new. I know I did.
References
[1] Nathan Myers. "A New and Useful Template Technique: 'Traits'," C++ Gems, edited by Stan Lippman (Cambridge University Press, 1996).
[2] Thomas Cargill. "Exception Handling, A False Sense of Security," C++ Gems, edited by Stan Lippman (Cambridge University Press, 1996).
Stanley Lippman was the software Technical Director for the Firebird segment of Disney's Fantasia 2000. He was recently technical lead on the ToonShooter image capture and playback system under Linux for DreamWorks Feature Animation and consulted with the Jet Propulsion Laboratory. He is currently IT Training Program Chair for You-niversity.com, an e-learning training company. He can be reached at stanleyl@you-niversity, www.you-niversity.com, and www.objectwrite.com.
