| Title: | C++ Gotchas: Avoiding Common Problems in Coding and Design |
| Author: | Stephen C. Dewhurst | Published: | Addison Wesley Professional, 2003 |
| Pages: | 324, softbound |
| Price: | $44.99 |
The publication of a "gotchas" book this late in C++'s evolution may seem a little strange. C++ has been a viable language for at least fifteen years; the C++ Standard has hardly changed in the past five. So you would think that language pitfalls would be common knowledge [1] by now. Yet even experienced C++ programmers get into trouble now and then, and nobody knows this as well as Steve Dewhurst, who has been a C++ teacher, author, and consultant for many years. Dewhurst seems to blame programmer complacency more than C++ complexity. In this book, the two great programming sins are ignorance of C++ basics and bad style. Experience alone does not prevent these human failings; sometimes we need to be prodded. To that end, C++ Gotchas is not just a catalog of C++ trouble spots, but a sort of running admonition to care about things we might have overlooked.
One of those things is the use of idiom. In spoken languages, an idiom is a commonly used phrase (e.g., "gotcha") that instantly conveys a clear meaning. Its meaning is clear just because the phrase is so widely used, not because of the words that make it up. In a programming language, an idiom is a common expression or technique that clearly conveys the intent of the programmer. Again, the idiom's clarity derives from its widespread use. A person who fails to learn spoken idioms puts himself at a great disadvantage; a programmer who doesn't use programming idioms makes everyone else work harder, especially maintainers of his code. In Dewhurst's book, appropriate use of idiom is part of good programming style, and good programming style keeps gotchas to a minimum.
Of course, if a pep talk on style were all we needed, this could have been a much thinner book. But we need specific information about the gotchas, regardless of their ultimate causes. Dewhurst lays out the details in nine chapters: Basics, Syntax, The Preprocessor, Conversions, Initialization, Memory and Resource Management, Polymorphism, Class Design, and Hierarchy Design. The origins of these gotchas range from simple absent-mindedness (like using delete instead of delete [] to deallocate an array), to sheer ignorance (referring to a conversion operator as a "cast"), to sloppiness (like mixing overloading and overriding of virtual functions without good reason). And by the way, arrested emotional development is now considered a gotcha as well; just look at gotcha #12. Storming out of the office is no longer excusable as "passionate" behavior, even if you are a coding wizard.
For most of the gotchas described in this book, there is not much to argue about. The choices that give rise to gotchas are clearly wrong — at least, in hindsight. Dewhurst provides convincing, if occasionally contrived examples to bring hidden errors to light. Yet a handful of items in this book are not so cut and dried. One of them is the preferred placement of the const keyword in a declaration:
const int *thisway; // pointer to constant integer int const *thatway; // same thing
Dewhurst favors the first form because it's what C++ programmers are used to seeing. It is a convention established long ago in the days of C. However, there is also a compelling rationale for the second form of declaration, and this form has gained something of a cult following in the C++ community. The second form enables us to state a simple rule: "const always qualifies the thing immediately to its left." This issue may seem ridiculously trivial, but it illustrates Dewhurst's overriding concern for convention. Programmers who are more familiar with convention than syntax quirks (perhaps most programmers) are apt to read the second form as a declaration of a constant pointer, which it is not. Dewhurst is not a language crusader; he just wants future maintainers of his code to get it right.
The word "maintenance" pops up often in this book, and it is not hard to see why. One of the ironies of modern computing is that while hardware is typically replaced in a matter of years, a lot of software hangs around for decades. Software often lives longer than its makers intended, as evidenced by the Y2K scare of a few years ago. Dewhurst frequently reminds readers to think of how their code will fare under maintenance. His advice here could be distilled into two design guidelines:
The hacks that we write today become the bugs of tomorrow. If you have not fallen victim to many C++ gotchas in recent years, you may not feel a pressing need to read this book. You might be wrong. C++ Gotchas is like a feedback mechanism from the future. It shows you all the stuff you are doing that will make trouble down the road.
This is not the first C++ book to deal with gotchas, of course. Many readers will think instantly of Scott Meyers' classic, Effective C++, and it is reasonable to ask how much is new in C++ Gotchas. I found about 15 items out of the 85 in Scott Meyers' Effective C++ and More Effective C++ that significantly overlapped with C++ Gotchas — not an excessive amount, and besides, these books differ quite a bit in focus. Dewhurst deals more in what I would call "subtle basics." This almost seems a contradiction in terms, but unfortunately it is not in C++. There is a lot of stuff to know, and even more that this book does not cover. For instance, this book has very little to say about use of the Standard C++ library or templates. It makes you wonder how many more potential gotchas books are out there. If Dewhurst wrote one or two of them, we could count ourselves very fortunate indeed.
[1] With apologies to Steve Dewhurst for stealing one of his trademark phrases. In past years, his "Common Knowledge" column has graced the pages of both C++ Report (now defunct) and CUJ.
Marc Briand is former Editor-in-Chief of C/C++ Users Journal. He currently develops ATE (Automated Test Equipment Software) for the Aerospace industry. He can be reached at marcbriand@cs.com.