C++ Gotchas Avoiding Common Problems in Coding and Design

by Dewhurst, Stephen C.

• ISBN13: 9780321125187
• ISBN10: 0321125185
• Edition: 1st
• Format: Paperback
• Copyright: 2002-11-26
• Publisher: Addison-Wesley Professional

Summary

"This may well be the best C++ book I have ever read. I was surprised by the amount I learned."--Matthew Wilson, Development Consultant, Synesis SoftwareC++ Gotchas is the professional programmer's guide to avoiding and correcting ninety-nine of the most common, destructive, and interesting C++ design and programming errors. It also serves as an inside look at the more subtle C++ features and programming techniques.This book discusses basic errors present in almost all C++ code, as well as complex mistakes in syntax, preprocessing, conversions, initialization, memory and resource management, polymorphism, class design, and hierarchy design. Each error and its repercussions are explained in context, and the resolution of each problem is detailed and demonstrated.Author Stephen Dewhurst supplies readers with idioms and design patterns that can be used to generate customized solutions for common problems. Readers will also learn more about commonly misunderstood features of C++ used in advanced programming and design. A companion Web site, located at http://www.semantics.org , includes detailed code samples from the book.Readers will discover: How to escape both common and complex traps associated with C++ How to produce more reusable, maintainable code Advanced C++ programming techniques Nuances of the C++ language C++ Gotchas shows how to navigate through the greatest dangers in C++ programming, and gives programmers the practical know-how they need to gain expert status. 0321125185B10212002

Author Biography

Stephen C. Dewhurst was among the first users of C++ at Bell Labs. He has more than eighteen years of experience

Table of Contents

Preface	xi
Acknowledgments	xv
Basics	1	(34)
Excessive Commenting	1	(3)
Magic Numbers	4	(2)
Global Variables	6	(2)
Failure to Distinguish Overloading from Default Initialization	8	(2)
Misunderstanding References	10	(3)
Misunderstanding Const	13	(1)
Ignorance of Base Language Subtleties	14	(5)
Failure to Distinguish Access and Visibility	19	(5)
Using Bad Language	24	(2)
Ignorance of Idiom	26	(3)
Unnecessary Cleverness	29	(2)
Adolescent Behavior	31	(4)
Syntax	35	(26)
Array/Initializer Confusion	35	(1)
Evaluation Order Indecision	36	(6)
Precedence Problems	42	(3)
for Statement Debacle	45	(3)
Maximal Munch Problems	48	(2)
Creative Declaration-Specifier Ordering	50	(1)
Function/Object Ambiguity	51	(1)
Migrating Type-Qualifiers	52	(1)
Self-Initialization	53	(2)
Static and Extern Types	55	(1)
Operator Function Lookup Anomaly	56	(2)
Operator -> Subtleties	58	(3)
The Preprocessor	61	(14)
#define Literals	61	(3)
#define Pseudofunctions	64	(2)
Overuse of #if	66	(6)
Side Effects in Assertions	72	(3)
Conversions	75	(50)
Converting through void	75	(4)
Slicing	79	(2)
Misunderstanding Pointer-to-Const Conversion	81	(1)
Misunderstanding Pointer-to-Pointer-to-Const Conversion	82	(4)
Misunderstanding Pointer-to-Pointer-to-Base Conversion	86	(1)
Pointer-to-Multidimensional-Array Problems	87	(2)
Unchecked Downcasting	89	(1)
Misusing Conversion Operators	90	(5)
Unintended Constructor Conversion	95	(3)
Casting under Multiple Inheritance	98	(2)
Casting Incomplete Types	100	(2)
Old-Style Casts	102	(1)
Static Casts	103	(3)
Temporary Initialization of Formal Arguments	106	(4)
Temporary Lifetime	110	(2)
References and Temporaries	112	(4)
Ambiguity Failure of dynamic-cast	116	(4)
Misunderstanding Contravariance	120	(5)
Initialization	125	(42)
Assignment/Initialization Confusion	125	(4)
Improperly Scoped Variables	129	(3)
Failure to Appreciate C++'s Fixation on Copy Operations	132	(4)
Bitwise Copy of Class Objects	136	(3)
Confusing Initialization and Assignment in Constructors	139	(2)
Inconsistent Ordering of the Member Initialization List	141	(1)
Virtual Base Default Initialization	142	(5)
Copy Constructor Base Initialization	147	(3)
Runtime Static Initialization Order	150	(3)
Direct versus Copy Initialization	153	(3)
Direct Argument Initialization	156	(2)
Ignorance of the Return Value Optimizations	158	(5)
Initializing a Static Member in a Constructor	163	(4)
Memory and Resource Management	167	(32)
Failure to Distinguish Scalar and Array Allocation	167	(4)
Checking for Allocation Failure	171	(2)
Replacing Global New and Delete	173	(3)
Confusing Scope and Activation of Member new and delete	176	(1)
Throwing String Literals	177	(3)
Improper Exception Mechanics	180	(5)
Abusing Local Addresses	185	(5)
Failure to Employ Resource Acquisition Is Initialization	190	(5)
Improper Use of auto_ptr	195	(4)
Polymorphism	199	(42)
Type Codes	199	(5)
Nonvirtual Base Class Destructor	204	(5)
Hiding Nonvirtual Functions	209	(3)
Making Template Methods Too Flexible	212	(2)
Overloading Virtual Functions	214	(2)
Virtual Functions with Default Argument Initializers	216	(2)
Calling Virtual Functions in Constructors and Destructors	218	(2)
Virtual Assignment	220	(4)
Failure to Distinguish among Overloading, Overriding, and Hiding	224	(6)
Failure to Grok Virtual Functions and Overriding	230	(6)
Dominance Issues	236	(5)
Class Design	241	(30)
Get/Set Interfaces	241	(4)
Const and Reference Data Members	245	(3)
Not Understanding the Meaning of Const Member Functions	248	(5)
Failure to Distinguish Aggregation and Acquaintance	253	(5)
Improper Operator Overloading	258	(3)
Precedence and Overloading	261	(1)
Friend versus Member Operators	262	(2)
Problems with Increment and Decrement	264	(4)
Misunderstanding Templated Copy Operations	268	(3)
Hierarchy Design	271	(36)
Arrays of Class Objects	271	(2)
Improper Container Substitutability	273	(4)
Failure to Understand Protected Access	277	(4)
Public Inheritance for Code Reuse	281	(4)
Concrete Public Base Classes	285	(1)
Failure to Employ Degenerate Hierarchies	286	(1)
Overuse of Inheritance	287	(5)
Type-Based Control Structures	292	(3)
Cosmic Hierarchies	295	(4)
Asking Personal Questions of an Object	299	(3)
Capability Queries	302	(5)
Bibliography	307	(2)
Index	309

Excerpts

This book is the result of nearly two decades of minor frustrations, serious bugs, late nights, and weekends spent involuntarily at the keyboard. This collection consists of 99 of some of the more common, severe, or interesting C++ gotchas, most of which I have (I'm sorry to say) experienced personally. The term "gotcha" has a cloudy history and a variety of definitions. For purposes of this book, we'll define C++ gotchas as common and preventable problems in C++ programming and design. The gotchas described here run the gamut from minor syntactic annoyances to basic design flaws to full-blown sociopathic behavior. Almost ten years ago, I started including notes about individual gotchas in my C++ course material. My feeling was that pointing out these common misconceptions and misapplications in apposition to correct use would inoculate the student against them and help prevent new generations of C++ programmers from repeating the gotchas of the past. By and large, the approach worked, and I was induced to collect sets of related gotchas for presentation at conferences. These presentations proved to be popular (misery loves company?), and I was encouraged to write a "gotcha" book. Any discussion of avoiding or recovering from C++ gotchas involves other subjects, most commonly design patterns, idioms, and technical details of C++ language features. This is not a book about design patterns, but we often find ourselves referring to patterns as a means of avoiding or recovering from a particular gotcha. Conventionally, the pattern name is capitalized, as in "Template Method" pattern or "Bridge" pattern. When we mention a pattern, we describe its mechanics briefly if they're simple but delegate detailed discussion of patterns to works devoted to them. Unless otherwise noted, a fuller description of a pattern, as well as a richer discussion of patterns in general, may be found in Erich Gamma et al.'sDesign Patterns. Descriptions of the Acyclic Visitor, Monostate, and Null Object patterns may be found in Robert Martin'sAgile Software Development. From the perspective of gotchas, design patterns have two important properties. First, they describe proven, successful design techniques that can be customized in a context-dependent way to new design situations. Second, and perhaps more important, mentioning the application of a particular pattern serves to document not only the technique applied but also the reasons for its application and the effect of having applied it. For example, when we see that the Bridge pattern has been applied to a design, we know at a mechanical level that an abstract data type implementation has been separated into an interface class and an implementation class. Additionally, we know this was done to separate strongly the interface from the implementation, so changes to the implementation won't affect users of the interface. We also know this separation entails a runtime cost, how the source code for the abstract data type should be arranged, and many other details. A pattern name is an efficient, unambiguous handle to a wealth of information and experience about a technique. Careful, accurate use of patterns and pattern terminology in design and documentation clarifies code and helps prevent gotchas from occurring. C++ is a complex programming language, and the more complex a language, the more important is the use of idiom in programming. For a programming language, an idiom is a commonly used and generally understood combination of lower-level language features that produces a higher-level construct, in much the same way patterns do at higher levels of design. Therefore, in C++ we can discuss copy operations, function objects, smart pointers, and throwing an exception without having to specify these concepts at their lowest level of implementation. It's important to emphasize that an idiom is not only a common combination of language fea