Gotcha #49: Failure to Appreciate C++'s Fixation on Copy Operations

Note that copy assignment and copy construction (along with other constructors and the destructor) are not inherited from base classes. Therefore, every class defines its own copy operations.

The default implementation of copy construction is to perform a member-by-member initialization. Member-by-member initialization has nothing to do with C-style bitwise copying of structures. Consider a simple class implementation:

template <int maxlen> 
class NBString {
 public:
   explicit NBString( const char *name );
   // . . .
 private:
   std::string name_;
   size_t len_;
   char s_[maxlen];
};

Assuming no copy operations are defined, the compiler will write some for us implicitly. These will be defined as public, inline members.

NBString<32> a( "String 1" ); 
// . . .
NBString<32> b( a );

The implicit copy constructor will perform a member-by-member initialization, invoking string's copy constructor to initialize b.name_ with a.name_, b.len_ with a.len_, and the elements of b.s_ with those of a.s_. (Actually, in an inspired burst of weirdness, the standard specifies that "scalar" types such as predefined types, enums, and pointers will be assigned within the implicit copy constructor rather than initialized. The group mental processes of the standards committee that led to this definition are beyond my ken, but the result will be the same—for these scalar types, anyway—whether assignment or initialization is used.)

b = a; 

Similarly, the implicit copy assignment operator will perform a member-by-member assignment, invoking string's assignment operator to assign a.name_ to b.name_, a.len_ to b.len_, and the elements of a.s_ to the corresponding elements of b.s_.

These implicit definitions of the copy operations will provide correct, conventional copy semantics. (See also Gotcha #81.) However, consider a slightly different implementation of the named, bounded string class:

class NBString { 
 public:
   explicit NBString( const char *name, int maxlen = 32 )
       : name_(name), len_(0), maxlen_(maxlen),
         s_(new char[maxlen] )
       { s_[0] = '\0'; }
   ~NBString()
       { delete [] s_; }
   // . . .
 private:
   std::string name_;
   size_t len_;
   size_t maxlen_;
   char *s_;
};

The constructor now sets the maximum size of the string, and storage for the character string is no longer physically within the NBString object. Now the implicit, compiler-provided copy operations are incorrect:

NBString c( "String 2" ); 
NBString d( c );
NBString e( "String 3" );
e = c;

The implicit copy constructor sets the s_ members of both c and d to the same heap-allocated buffer. The buffer will suffer a double deletion when the destructors for d and then c attempt to delete the same memory. Similarly, when c is assigned to e, the memory to which e.s_ refers is left dangling when e.s_ is set to the same buffer as c.s_, with results similar to those above. (See also Gotcha #53 for a short discussion of the implications of compiler-generated copy assignment in the presence of virtual base classes.)

A correct implementation must take over from the compiler the task of writing the copy operations in their entirety:

class NBString { 
 public:
   // . . .
   NBString( const NBString & );
   NBString &operator =( const NBString & );
 private:
   std::string name_;
   size_t len_;
   size_t maxlen_;
   char *s_;
};
// . . .
NBString::NBString( const NBString &that )
   : name_(that.name_), len_(that.len_), maxlen_(that.maxlen_),
     s_(strcpy(new char[that.maxlen_], that.s_))
   {}
NBString &NBString::operator =( const NBString &rhs ) {
   if( this != &rhs ) {
       name_ = rhs.name_;
       char *temp = new char[rhs.maxlen_];
       len_ = rhs.len_;
       maxlen_ = rhs.maxlen_;
       delete [] s_;
       s_ = strcpy( temp, rhs.s_ );
   }
   return *this;
}

Every class designer must take careful consideration of copy operations. They must either be supplied explicitly (and maintained with every change to the class's implementation), be generated implicitly by the compiler (with this decision revisited with every change to the class's implementation), or be denied using the coding idiom below:

class NBString { 
 public:
   // . . .
 private:
   NBString( const NBString &);
   NBString &operator =( const NBString & );
   // . . .
};

Declaring—but not defining—private copy operations has the effect of "turning off" copying for the class. The compiler will not attempt to provide implicit versions of the operations, and most code will not have access to the private members. Any accidental copying performed by members or friends of the class will be caught as an undefined function at link time.

It's pretty much impossible to talk your way past the compiler on the subject of implementing copy operations. The code below shows three creative but futile attempts to defeat the compiler:

class Derived; 
class Base {
 public:
   Derived &operator =( const Derived & );
   virtual Base &operator =( const Base & );
};
class Derived : public Base {
 public:
   using Base::operator =; // hidden
   template <class T>
   Derived &operator =( const T & ); // not a copy assign
   Derived &operator =( const Base & ); // not a copy assign
};

We already know that copy operations aren't inherited, but the using-declaration that imports the rather accommodating nonvirtual base class assignment operator doesn't prevent the compiler from writing one either, and the compiler's implicit version hides the one imported explicitly. (Note also that the base class mentions the derived class explicitly, which is poor design. See Gotcha #69.)

The use of a template assignment member function doesn't help; template members are never used to implement copy operations (see Gotcha #88). The virtual copy assignment from the base class is overridden in the derived class, but the overriding derived class assignment operator is not a copy assignment (see Gotcha #76). The C++ language is insistent: either you write the copy operations or the compiler will, and no fooling around.