9780321125187

"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

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

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

What is included with this book?

The New copy of this book will include any supplemental materials advertised. Please check the title of the book to determine if it should include any access cards, study guides, lab manuals, CDs, etc.

The Used, Rental and eBook copies of this book are not guaranteed to include any supplemental materials. Typically, only the book itself is included. This is true even if the title states it includes any access cards, study guides, lab manuals, CDs, etc.

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

Amazon no longer offers textbook rentals. We do!

C++ Gotchas Avoiding Common Problems in Coding and Design

C++ Gotchas Avoiding Common Problems in Coding and Design

0321125185

Summary

Author Biography

Table of Contents

Supplemental Materials

Excerpts

Write a Review