Gotcha #50: Bitwise Copy of Class Objects

Nothing is essentially wrong with allowing the compiler to write copy operations implicitly, though it's generally best to allow these implicit definitions only for simple classes or, to be more precise, only for classes that have simple structure. In fact, for simple classes, it's often a good idea to cede this job to the compiler for reasons of efficiency. Consider a class that's really just a simple collection of data:

struct Record { 


   char name[maxname];


   long id;


   size_t seq;


};

It makes a lot of sense to allow the compiler to implement copy operations for this simple class. A class of this kind is known as a POD (for Plain Old Data; see Gotcha #9), which is basically a C-like struct. The implicit copy operations in such cases are carefully defined by the standard to match the copy semantics of C structs, which are implemented as bitwise copy.

In particular, if a given platform has a "copy n bytes real fast" instruction, the compiler is free to use it in the implementation of the bitwise copy. This kind of optimization can be appropriate even for non-POD classes. The copy operations for the original, templated implementation of NBString of Gotcha #49 could reasonably be implemented by invoking the appropriate copy operation for the string member name_ followed by a fast bitwise copy of the remainder of the object.

Occasionally, an implementer of a class decides to take control of the bitwise copy decision. This is usually a mistake, because the compiler is much more cognizant of both the class implementation details and the platform specifics than the programmer. A handcrafted bitwise copy is usually both slower and buggier than the compiler's version:

class Record { 


 public:


   Record( const Record &that )


       { *this = that; }


   Record &operator =( const Record &that )


       { memcpy( this, &that, sizeof(Record) ); return *this; }


   // . . .


 private:


   char name[maxname];


   long id;


   size_t seq;


};

Our Record POD is growing into a real class, so we've provided some explicit copy operations for it. This was unnecessary, since the compiler would have provided perfectly efficient and correct versions. The real problem comes when the Record class continues its development:

class Record { 


 public:


   virtual ~Record();


   Record( const Record &that )


       { *this = that; }


   Record &operator =( const Record &that )


       { memcpy( this, &that, sizeof(Record) ); return *this; }


   // . . .


 private:


   char name[maxname];


   long id;


   size_t seq;


};

Now things don't look so good. A bitwise copy no longer serves the structure of the class. The addition of a virtual function causes the compiler to add mechanism to the class implementation, typically a pointer to a virtual function table (see Gotcha #78).

Implicit copy operations generated by the compiler take care to handle the implicit class mechanism appropriately: the copy constructor sets the pointer appropriately, and the copy assignment operator takes care not to modify it. Our memcpy implementation, however, will overwrite the virtual function table pointer immediately after it's set in the copy constructor, and the copy assignment will overwrite it as well. Many other changes to the class could provoke similar bugs: derivation from a virtual base class, adding a data member that defines nontrivial copy operations, use of a pointer to unencapsulated storage, and so on.

In general, it's unwise to employ a hand-coded bitwise copy of any class object without hard data that show both a need and a sizable improvement in performance. If you are employing such an approach, carefully revisit the decision with every change to the implementation of the class.

Of course, using bitwise class copy outside a class's implementation is even less recommended. Implementing a copy operation with memcpy is daring. Bit-blasting on the sly is suicidal:

extern Record *exemplaryRecord; 


char buffer[sizeof(Record)];


memcpy( buffer, exemplaryRecord, sizeof(buffer) );

Whoever wrote this code is probably embarrassed about it (or should be) and has hidden it away in an implementation file remote from the code that implements Record. Any changes to Record that are incompatible with a bitwise copy won't be detected until they manifest as a runtime error. If it's essential to write code like this, it must be done in such a way that the class's own copy operations are invoked (see Gotcha #62):

(void) new (buffer) Record( *exemplaryRecord );