More Books
C++ Gotchas: Avoiding Common Problems in Coding and Design
Main Page
Table of content
Copyright
Addison-Wesley Professional Computing Series
Preface
Acknowledgments
Chapter 1. Basics
Gotcha #1: Excessive Commenting
Gotcha #2: Magic Numbers
Gotcha #3: Global Variables
Gotcha #4: Failure to Distinguish Overloading from Default Initialization
Gotcha #5: Misunderstanding References
Gotcha #6: Misunderstanding Const
Gotcha #7: Ignorance of Base Language Subtleties
Gotcha #8: Failure to Distinguish Access and Visibility
Gotcha #9: Using Bad Language
Gotcha #10: Ignorance of Idiom
Gotcha #11: Unnecessary Cleverness
Gotcha #12: Adolescent Behavior
Chapter 2. Syntax
Gotcha #13: Array/Initializer Confusion
Gotcha #14: Evaluation Order Indecision
Gotcha #15: Precedence Problems
Gotcha #16: 'for' Statement Debacle
Gotcha #17: Maximal Munch Problems
Gotcha #18: Creative Declaration-Specifier Ordering
Gotcha #19: Function/Object Ambiguity
Gotcha #20: Migrating Type-Qualifiers
Gotcha #21: Self-Initialization
Gotcha #22: Static and Extern Types
Gotcha #23: Operator Function Lookup Anomaly
Gotcha #24: Operator '->' Subtleties
Chapter 3. The Preprocessor
Gotcha #25: '#define' Literals
Gotcha #26: '#define' Pseudofunctions
Gotcha #27: Overuse of '#if'
Gotcha #28: Side Effects in Assertions
Chapter 4. Conversions
Gotcha #29: Converting through 'void *'
Gotcha #30: Slicing
Gotcha #31: Misunderstanding Pointer-to-Const Conversion
Gotcha #32: Misunderstanding Pointer-to-Pointer-to-Const Conversion
Gotcha #33: Misunderstanding Pointer-to-Pointer-to-Base Conversion
Gotcha #34: Pointer-to-Multidimensional-Array Problems
Gotcha #35: Unchecked Downcasting
Gotcha #36: Misusing Conversion Operators
Gotcha #37: Unintended Constructor Conversion
Gotcha #38: Casting under Multiple Inheritance
Gotcha #39: Casting Incomplete Types
Gotcha #40: Old-Style Casts
Gotcha #41: Static Casts
Gotcha #42: Temporary Initialization of Formal Arguments
Gotcha #43: Temporary Lifetime
Gotcha #44: References and Temporaries
Gotcha #45: Ambiguity Failure of 'dynamic_cast'
Gotcha #46: Misunderstanding Contravariance
Chapter 5. Initialization
Gotcha #47: Assignment/Initialization Confusion
Gotcha #48: Improperly Scoped Variables
Gotcha #49: Failure to Appreciate C++'s Fixation on Copy Operations
Gotcha #50: Bitwise Copy of Class Objects
Gotcha #51: Confusing Initialization and Assignment in Constructors
Gotcha #52: Inconsistent Ordering of the Member Initialization List
Gotcha #53: Virtual Base Default Initialization
Gotcha #54: Copy Constructor Base Initialization
Gotcha #55: Runtime Static Initialization Order
Gotcha #56: Direct versus Copy Initialization
Gotcha #57: Direct Argument Initialization
Gotcha #58: Ignorance of the Return Value Optimizations
Gotcha #59: Initializing a Static Member in a Constructor
Chapter 6. Memory and Resource Management
Gotcha #60: Failure to Distinguish Scalar and Array Allocation
Gotcha #61: Checking for Allocation Failure
Gotcha #62: Replacing Global New and Delete
Gotcha #63: Confusing Scope and Activation of Member 'new' and 'delete'
Gotcha #64: Throwing String Literals
Gotcha #65: Improper Exception Mechanics
Gotcha #66: Abusing Local Addresses
Gotcha #67: Failure to Employ Resource Acquisition Is Initialization
Gotcha #68: Improper Use of 'auto_ptr'
Chapter 7. Polymorphism
Gotcha #69: Type Codes
Gotcha #70: Nonvirtual Base Class Destructor
Gotcha #71: Hiding Nonvirtual Functions
Gotcha #72: Making Template Methods Too Flexible
Gotcha #73: Overloading Virtual Functions
Gotcha #74: Virtual Functions with Default Argument Initializers
Gotcha #75: Calling Virtual Functions in Constructors and Destructors
Gotcha #76: Virtual Assignment
Gotcha #77: Failure to Distinguish among Overloading, Overriding, and Hiding
Gotcha #78: Failure to Grok Virtual Functions and Overriding
Gotcha #79: Dominance Issues
Chapter 8. Class Design
Gotcha #80: Get/Set Interfaces
Gotcha #81: Const and Reference Data Members
Gotcha #82: Not Understanding the Meaning of Const Member Functions
Gotcha #83: Failure to Distinguish Aggregation and Acquaintance
Gotcha #84: Improper Operator Overloading
Gotcha #85: Precedence and Overloading
Gotcha #86: Friend versus Member Operators
Gotcha #87: Problems with Increment and Decrement
Gotcha #88: Misunderstanding Templated Copy Operations
Chapter 9. Hierarchy Design
Gotcha #89: Arrays of Class Objects
Gotcha #90: Improper Container Substitutability
Gotcha #91: Failure to Understand Protected Access
Gotcha #92: Public Inheritance for Code Reuse
Gotcha #93: Concrete Public Base Classes
Gotcha #94: Failure to Employ Degenerate Hierarchies
Gotcha #95: Overuse of Inheritance
Gotcha #96: Type-Based Control Structures
Gotcha #97: Cosmic Hierarchies
Gotcha #98: Asking Personal Questions of an Object
Gotcha #99: Capability Queries
Bibliography

Gotcha #81: Const and Reference Data Members

One good piece of general advice is "Anything that can be const should be const." A related piece of good advice is "If something is not always used as a const, don't declare it to be const." Taken together, these pieces of advice imply that one should examine the current and expected future uses of a construct and make it "as const as possible, but no more so."

In this item, I'll attempt to convince you that it rarely makes sense to declare const or reference data members in a class. Const and reference data members tend to make classes harder to work with, require unnatural copy semantics, and encourage maintainers to introduce dangerous changes.

Let's look at a simple class with const and reference data members:

class C { 
 public:
   C();
   // . . .
 private:
   int a_;
   const int b_;
   int &ra_;
};

The constructor must initialize const and reference data members:

C::C() 
   : a_( 12 ), b_( 12 ), ra_( a_ )
   {}

So far, so good. We can declare objects of type C and initialize them:

C x; // default ctor 
C y( x ); // copy ctor

Oops! Where did that copy constructor come from? The compiler wrote it for us, and by default, that copy constructor will perform a member-by-member initialization of the members of y with the corresponding members of x (see Gotcha #49). Unfortunately, this default implementation will set the ra_ reference in y to the a_ in x. Since we're on the subject of good, general advice, another such piece of advice is "Consider writing copy operations for any class that contains a handle (generally a pointer or reference) to other data":

C::C( const C &that ) 
   : a_( that.a_ ), b_( that.b_ ), ra_( a_ )
   {}

Let's continue to use our C objects:

x = y; // error! 

The problem here is that the compiler is unable to generate an assignment operation for us. By default, it will attempt to generate an assignment operation that simply assigns each data member of y to the corresponding data member of x. For objects of type C, that isn't possible, since the b_ and ra_ members can't be assigned. This is just as well, really, since such an assignment operation would exhibit the same incorrect behavior as that of the default copy constructor.

The problem is, it's not a simple task to write the assignment operator. Consider a first attempt:

C &C::operator =( const C &that ) { 
   a_ = that.a_; // OK
   b_ = that.b_; // error!
   return *this;
}

It's not legal to assign to a constant. The danger here is that a "creative" maintainer of our code will attempt to perform the assignment anyway. Usually, the first recourse is to a cast:

int *pb = const_cast<int *>(&b_); 
*pb = that.b_;

Now, in point of fact, this code will probably not cause any runtime problems, since it's unlikely that the b_ member will be in a read-only segment when it's part of a non-constant C object. However, one can hardly call this a natural implementation, and this trick won't work on a reference member. (Note that in this particular assignment operator, it was not necessary to attempt to rebind the reference data member of C, since it was already referring to the a_ member of its own object.)

Some excessively creative maintainers might take a different tack. Rather than assign y to x, they'll destroy x entirely and reinitialize it with y:

C &C::operator =( const C &that ) { 
   if( this != &that ) {
       this->~C(); // call dtor
       new (this) C(that); // copy ctor
   }
   return *this;
}

A lot of ink has been expended over the years in proposing and, ultimately, rejecting this approach. Even though it may work in this limited case—for a time—it's complex, doesn't scale, and is likely to cause problems in the future. Consider what would happen if C ultimately became a base class. It's likely that a derived class assignment operator would call C's assignment operator. The destructor call, if virtual, will destroy the entire object, not just the C part. The destructor call, if nonvirtual, will have undefined behavior. Avoid this approach.

The easiest and most straightforward approach is to simply avoid const and reference data members. Since all our data members are private (they are private, aren't they?), we already have adequate protection from accidental modification. If, on the other hand, the intent of using const or reference data members is to keep the compiler from generating a default assignment operator, a more idiomatic way will achieve that (see Gotcha #49):

class C { 
   // . . .
 private:
   int a_;
   int b_;
   int *pa_;
   C( const C & ); // disallow copy construction
   C &operator =( const C & ); // disallow assignment
};

Const or reference data members are rarely needed. Avoid them.