Books in Brief

C++ Gotchas: Avoiding Common Problems in Coding and Design
Stephen C. Dewhurst
352 pages
Addison-Wesley Professional
$44.99
ISBN: 0321125185
http://www.awprofessional.com/

C++ Gotchas, by Stephen C. Dewhurst, follows squarely in the tradition of Scott Meyers's Effective C++ series (see the October 2001 review), Herb Sutter's Exceptional C++ books (see the June 2002 review), and Marshall Cline's C++ FAQ (http://www.parashift.com/c++-faq-lite/). Specifically, they all attempt to codify the rules of C++ idioms to improve your ability to code portable, maintainable, and efficient C++ code. More than simple "style" advice, they get to the heart of the matter by showing how easy things can be when done right and how chaos can result from other choices. C++ evolves idioms from the community of programmers and their wisdom prevents your peril. It's my firm belief that every C++ developer should read one or more idiomatic texts every year and keep them close at hand to resolve design arguments or simply articulate why you chose an implementation.

Readers that have had three semesters of C++ or equivalent industry experience in the language will benefit most from C++ Gotchas. Some familiarity with design patterns (http://hillside.net/patterns/DPBook/DPBook.html) will be required to get 100 percent out of the book. Fortunately, the author often presents simple implementations of patterns by way of a refresher.

Dewhurst organizes a total of 99 Gotchas, a more exhaustive array than seen in any of the aforementioned texts. Broadly, the Gotchas are organized into topics such as conversions, initialization, memory and resource management, polymorphism, class and hierarchy design, and so on. Clearly these topics are intrinsic to the internal construction of any significant C++ project.

I have to agree with an online reviewer who found Gotcha #7, Ignorance of Basic Language Subtleties, to be guilty of Gotcha #11, Unnecessary Cleverness. I've seen too many cases where nested ternary operators became a train wreck. Similarly, the wanton placement of switch case labels in different parts of a nested loop is an exercise in

obfuscation. Modern optimizing compilers and Moore's Law make such shortcuts seem obsessive at best.

I always learn (or relearn) something new whenever I pick up an idiomatic text. Gotcha #14, Evaluation Order Indecision, explains that precedence and associativity of operators doesn't change evaluation order:

a = p() + q() * r()</p>

Here, p(), q(), and r() could be legally evaluated in six different possible orders. Precedence assures us only that the results of q() and r() will be multiplied before being added to p().

Often, Gotchas from different topics are related and sometimes repeat points. Several Gotchas cover the rules on how to interpret and write const declarations. Since const declarations can easily fool some programmers some of the time, extra detail here helps. Gotcha #30, Slicing, and #95, Concrete Base Classes, remind us to avoid concrete base classes by demonstrating their flaws. I found Gotchas #39-41 on the folly of all kinds of nondynamic casts quite sobering.

In the chapter "Memory and Resource Management," Gotchas #64-65 enlightened me about common exception-handling flaws. Specifically, the notion that you should only throw exception objects rather than anything of a predefined type (such as int or string). Also, Dewhurst lucidly explains the need to avoid throwing pointers.

On Polymorphism, the author covers many potential trouble areas in failures to distinguish among overloading, overriding, and hiding (Gotcha #77). Things can get even murkier when virtual functions and dominance enter the mix (Gotchas #78-79).

Last, Class Design picks up on many perennially thorny issues including operator overloading, friends versus members, and aggregation versus acquaintance. Hierarchy design looks at bigger picture issues such as object queries, universal hierarchies, and containers.

Stephen C. Dewhurst's C++ Gotchas might be a valuable addition to your knowledgebase of C++ idioms, whether designing new code or refactoring legacy code.