Gotcha #76: Virtual Assignment

Assignment may be virtual, but use of virtual assignment is rarely justified. For example, we may have a container hierarchy that supports virtual assignment through the base class interface:

template <typename T> 


class Container {


 public:


   virtual Container &operator =( const T & ) = 0;


   // . . .


};


template <typename T>


class List : public Container<T> {


   List &operator =( const T & );


   // . . .


};


template <typename T>


class Array : public Container<T> {


   Array &operator =( const T & );


   // . . .


};


// . . .


Container<int> &c( getCurrentContainer() );


c = 12; // is the meaning clear?

Note that this is not a copy assignment, since the argument type is not the same as the type of the container. (See Gotcha #77 for the reason why the return types of the overriding derived class assignment operators may differ from those of the base class assignment.) This assignment is intended to set all the elements of a Container to the same value. Unfortunately, experience shows that this use of assignment is sometimes misinterpreted, with some users assuming that the assignment changes the size of the container and some users assuming that the assignment sets the value of the first element only (see Gotcha #84). A safer interface would abandon operator overloading in favor of an unambiguous non-operator function:

template <typename T> 


class Container {


 public:


   virtual void setAll( const T &newElementValue ) = 0;


   // . . .


};


// . . .


Container<int> &c( getCurrentContainer() );


c.setAll( 12 ); // meaning is clear

Copy assignment may also be virtual, but this is rarely a good idea, since the derived class copy assignment operator doesn't override the base class copy assignment:

template <typename T> 


class Container {


 public:


   virtual Container &operator =( const Container & ) = 0;


   // . . .


};


template <typename T>


class List : public Container<T> {


   List &operator =( const List & ); // doesn't override!


   List &operator =( const Container<T> & ); // overrides . . .


   // . . .


};


// . . .


Container<int> &c1 = getMeAList();


Container<int> &c2 = getMeAnArray();


c1 = c2; // assign an array to a list?!?

Virtual copy assignment would permit the assignment of one derived class object to another derived class object of a different type! There are few circumstances where this makes sense. Avoid virtual copy assignment.

One might try to make a case for virtual copy assignment in the Container hierarchy above, since it could make sense to assign the content of one container (an array) to another container (a list). However, this assumes that each container type knows about all the others (which is usually a bad design practice) or that a rather involved framework is employed. A simpler and therefore better solution would be to employ a nonvirtual copyContent member or non-member function of Container written in terms of virtual functions or iterators that extract element values from the source of the copy and insert the values into the target of the copy:

Container<int> &c1 = getMeAList(); 


Container<int> &c2 = getMeAnArray();


c1.copyContent( c2 ); // copy content of array to list

One example of this approach is found in the standard library containers, where it's possible to initialize a container with a sequence obtained from an existing container of different type:

vector<int> v; 


// . . .


list<int> el( v.begin(), v.end() );

Often, virtual copy construction is a better design approach than virtual assignment. Of course, C++ has no virtual constructors, but we do have a "virtual constructor" idiom, now more generally known as the Prototype pattern. Rather than assign an object of unknown type, we clone it. The base class provides a pure virtual clone operation that is overridden in derived classes to return an exact copy of themselves. Typically, the copy is generated with the derived class's copy constructor, and we can think of the clone operation as a kind of virtual copy construction:

gotcha90/container.h

template <typename T> 


class Container {


 public:


   virtual Container *clone() const = 0;


   // . . .


};


template <typename T>


class List : public Container<T> {


   List( const List & );


   List *clone() const


       { return new List( *this ); }


   // . . .


};


template <typename T>


class Array : public Container<T> {


   Array( const Array & );


   Array *clone() const


       { return new Array( *this ); }


   // . . .


};


// . . .


Container<int> *cp = getCurrentContainer();


Container<int> *cp2 = cp->clone();

Use of the Prototype pattern allows us to say, effectively, "I don't know precisely what I'm pointing to, but I want another one just like it!"