Title: Coping with Copying in C++

A fruitful source of examples for exploring the impact and use of class hierarchies is a graphics editor that allows primitive and complex shapes to be drawn:

class graphic {...};
class ellipse : public graphic {...};
class rectangle : public graphic {...};
...

This hierarchy is based on classification: it is abstract at the root and concrete at the leaves. When we add a new ellipse to our picture, the code knows at the point of creation (somewhere) what the actual creation type of the object is. However, beyond that its usage is entirely through the base:

class picture
{
    ...
private:
    ...
    std::list<graphic *> graphics;
};

One feature we expect in a fully functioning graphics editor is the ability to copy and paste shapes around. Given a graphic, we need a new copy of it with the same state (although we may offset it by a couple of grid lines so that it does not mask the original) and behaviour. The following will not work:

class picture
{
  ...
  void copy(const graphic *original)
  {
      graphic *copy = new graphic(*original); 
      // won't compile
      ...
  }
  ...
};

It is possible to do this in some languages, such as Ada 95, but not in C++: graphic is an abstract base class, and the specific request we have here is to create a new instance of something that is incomplete - you will typically be greeted by a compiler message that is similarly incomplete in its helpfulness.

We can make an attempt at explicit type laundering as follows:

class picture
{
  ...
  void copy(const graphic *original)
  {
    graphic *copy = 0;
    if(typeid(*original) == typeid(rectangle))
        copy = new rectangle(
             static_cast<const rectangle &>
             (*original));
    else if(typeid(*original) == 
                             typeid(ellipse))
        copy = new ellipse(
            static_cast<const ellipse &>
            (*original));
    ...
  }
  ...
};

Such a microarchitecture is brittle in the face of change - what if we add a new class to the hierarchy? - and clunky in its expression - large cascading control structures seem to suggest a joy of typing rather than of elegance, economy and extensibility. In essence, this solution is best described as a hack, and it is a classic misuse of runtime type information (RTTI).

The location of the knowledge of the exact type of the source object for copying is within that object. Therefore we should turn the problem around and ask it for a copy of itself. Provide the entry point for this capability in the base class and realise its implementation in the concrete derived classes, each of which knows how to make a copy of itself:

class graphic
{
public:
    virtual graphic *clone() const = 0;
    ...
};

class rectangle : public graphic
{
public:
    virtual rectangle *clone() const;
    ...
};

class ellipse : public graphic
{
public:
    virtual ellipse *clone() const;
    ...
};

class picture
{
public:
    ...
    void copy(const graphic *original)
    {
        graphic *copy = original->clone();
        ...
    }
    ...
};

This tidy solution uses the natural form of RTTI found within object-oriented systems: objects encapsulate knowledge of not only of their state but also of their runtime type, which is decoupled from usage through inheritance and polymorphism.

Therefore, the system is more loosely coupled, more open to change by extension, and is expressed at a more abstract level. It is possible to refactor cloning capability more cohesively into a separate INTERFACE CLASS. Any new class in the hierarchy must implement the protocol for cloning by defining an appropriate clone member function, which places greater responsibility on the derived class implementor; implementing derived classes with a REFLEXIVE MIX-IN can simplify this, bringing the responsibility for some of the mechanism back into the framework. With an established protocol, copying and object lifetime management of cloned objects can be automated relatively transparently with a QUALIFIED SMART POINTER.

CLONING resolves the problems deep type copying when only a shallow type is known, i.e. a copy of the specialised type rather than the generalised type is required, but objects are manipulated through the generalised type. This distinction between profound copying versus superficial copying with respect to type marks the distinction between CLONING and use of an ordinary copy constructor to create copies^[3].

Another name for this technique is VIRTUAL COPY CONSTRUCTOR, as it is a special case of VIRTUAL CONSTRUCTOR [Coplien1992, Gamma-1995]. The specialisation is that it is a FACTORY METHOD [Gamma-1995] where the product and producer are instances of the same class. Note, however, that this is not the same as the PROTOTYPE pattern [Gamma-1995], or exemplar based programming [Coplien1992]. The distinction can be found in PROTOTYPE's intent:

Thus, in a C++ realisation PROTOTYPE will typically use CLONING, but a collaboration that uses CLONING is not necessarily an implementation of PROTOTYPE. In the graphics editor we could use PROTOTYPE to simplify the initial creation of new graphical objects [Gamma-1995], and this would build on our use of CLONING to give a PROTOTYPE collaboration.

Note that in the implementation of CLONING shown in the example derived classes specialised clone's return type. Covariant return types may be declared in C++ for virtual functions returning pointers or references. As inheritance implies specialisation, this makes perfect sense: when we clone a rectangle, we do not simply get a graphic back; we know we get a rectangle. Covariant return types allow us to express this constraint more precisely, and sidestep suspicious casts often found in code when you know something more about the type of an object being copied. Contrast this with cloning in Java which normally requires a downcast for the clone to be of any use.

However, using covariant return types is a game of challenge your compiler; it is typically the case that your compiler loses such a contest at present. Although handling covariant return types was the first extension considered during the standardisation of C++ and was adopted in 1992 [Stroustrup1994], it would be fair to say that compiler writers have not so much been slow to catch up as to not even get to the starting blocks with this feature.

Abstract classes, such as graphic, are often considered partial implementations. As such they represent a focus for adding features to a hierarchy. In the case of copying this means that graphic must offer CLONING as part of its public interface, although it can offer no meaningful default implementation.

However, CLONING as a cohesive concept in its own right. If we are building a large framework we may find it recurring across root abstract classes.

There is also the possibility that in such a framework, any multiple inheritance will lead to repeated inheritance of a clone member function. Assuming signature compatibility, i.e. both called clone and both qualified as const, a single clone using a covariant return type resolves the basic conflicts, ensuring that cloning of an object results in cloning the whole object and not its parts. However, if this is not followed the concept of cloning will be stated (and implemented) more than once in the interface of the derived class, reducing its cohesion.

Define a separate INTERFACE CLASS to express the common capability of derived classes, i.e. a class to represent the contract and many derived classes to fulfil it and express the implementation detail. This class has no data and the only ordinary member functions are declared public and pure virtual:

class cloneable
{
public:
    virtual ~cloneable();
    virtual cloneable *clone() const = 0;
};

If it is intended that objects can be deleted via a pointer to the INTERFACE CLASS the destructor should be declared public and virtual. It is a matter of personal taste as to whether or not the destructor is also declared pure virtual as it must be defined either way. Personal preference is not to declare it as pure virtual as the occurrence of this usage - i.e. pure virtual declaration but with definition - is sufficiently rare that the majority of C++ developers are not familiar with it, and automatically take pure virtual to be equivalent to "has no definition".

On the other hand, if objects should not be deleted via the INTERFACE CLASS it should not offer this ability, i.e. the destructor should be made protected and non-virtual thus deferring full responsibility for destruction policy to derived classes^[4]:

class cloneable
{
public:
    virtual cloneable *clone() const = 0;
protected:
    ~cloneable();
};

In either case, the body of the destructor should be empty. For cloning it seems to make sense to support public deletion, and so we will go with the first option.

Polymorphic assignment makes little sense, causes many problems (both philosophical and pragmatic) and should not be supported. Deferring policy responsibility to derived classes again resolves this. To prevent any default assignment generation (and the same applies for preventing default copy construction), the copy assignment operator should be declared private but should be left undefined:

class cloneable
{
    ...
private:
    cloneable &operator=(const cloneable &);
};

Otherwise assignment should be declared protected.

In addition to resolving the deferred decisions, derived classes implementing the INTERFACE CLASS should use virtual inheritance:

class graphic : public virtual cloneable {...};

Interfaces express capabilities of objects, and where the object's class multiply inherits from other classes that ultimately inherit from the same interface, the object still only expresses these capabilities once. The default inheritance mechanism leads to the idea that any repeated inheritance represents multiple instances of the repeated class, with multiple instances of the data; this is not meaningful in the case of an INTERFACE CLASS. Nonetheless, tied to this is the idea that functions are still associated with separate subobjects and that the derived class is substitutable for one of two occurrences of the base class - an ambiguity that must be resolved by the programmer - rather than being directly substitutable for the interface, which is after all the point of defining one! Therefore, an INTERFACE CLASS should be a virtual base class to resolve this tension.

The result of expressing usage protocol as an INTERFACE CLASS is a clean separation between interface and implementation, i.e. contract and fulfilment, allowing derived classes to focus on the implementation detail. Codifying a common and cohesive public interface as an INTERFACE CLASS encourages a coherent framework design. Where the code structure of the implementation is similar for each derived class, varying only in its dependence on the type name of the derived class - as it will be in this case - consider using a REFLEXIVE MIX-IN to factor out the details completely.

The explicit and physical separation of interface from implementation is key to modern component based development (CBD) as typified by COM and CORBA. Interfaces as language elements distinct from implementation classes are an old idea that can be found in non-mainstream languages such as Emerald, Guide, Portlandish and Sather, and more recently (and popularly) in Java. Interfaces are considered to be separate modelling elements in UML [Booch-1999], although the issue is a little muddled by introducing both a type/class separation and a fashionable interpretation of interface. In C++, INTERFACE CLASS is the idiomatic practice that expresses such ideas [Henney1998b]. It is a form of mix-in class that provides protocol only.

A distinction that I have found useful is that an INTERFACE CLASS represents the usage type, or some aspect of the usage, of an object, whereas its actual runtime type is only ever used for construction, i.e. a creation type [Barton-1994]. This decoupling allows us to view and discuss interfaces as the seams in our system [Booch-1999].

Classes that implement a common capability expressed at the top of a hierarchy, such as with an INTERFACE CLASS, may end up with structurally very similar code. For CLONING, the implementation of clone is a matter of returning a newly allocated copy of the current instance:

class rectangle : public graphic
{
public:
    virtual rectangle *clone() const
    {
        return new rectangle(*this);
    }
    ...
};

class ellipse : public graphic
{
public:
    virtual ellipse *clone() const
    {
        return new ellipse(*this);
    }
    ...
};

This is potentially tedious, and is prone to cut and paste errors. At an aesthetic level it is also not pleasing: repetition implies that there is an abstraction missing. However, the dependency on the type of the derived class implies that a conventional mix-in class that provides common partial implementation cannot be used.

Define a template class that is intended for use as a base. It defines the common code in terms of the varying part [Coplien1999], i.e. the derived class, which is supplied as a template parameter:

template<class derived>
class cloner : public virtual cloneable
{
public:
    virtual derived *clone() const;
    ...
};

Because cloner classes derive from cloneable, clone must return a type that is ultimately derived from cloneable. Because derived must be derived from cloner<derived> it satisfies this requirement. Knowing the exact type of the derived class also allows cloner<derived> to use this as an instance of derived to create a copy of the correct type:

template<class derived>
derived *cloner<derived>::clone() const
{
    return new derived(static_cast<const derived &>(*this));
}

To take advantage of this facility requires that derived classes derived from the template using themselves as the template parameter:

class rectangle : public graphic, public cloner<rectangle>
{
public:
    rectangle(const rectangle &);
    ...
};

class ellipse : public graphic, public cloner<ellipse>
{
public:
    ellipse(const ellipse &);
    ...
};

With the exception that each derived class must provide a meaningful copy constructor, no further implementation work is needed: all of the implementation comes from the REFLEXIVE MIX-IN. The constraints on the relationship between the derived class and template parameter are sufficiently well enforced by the type system, and limitations on the use of static_cast as opposed to traditional casts, that misuse is caught at compile time. The code also illustrates an example of repeated inheritance of cloneable via two different routes: via graphic and also via cloner. Following the INTERFACE CLASS idiom's practice of using virtual base classes means that CLONING applies to the class once rather than many times.

The cloner template is effectively abstract even though it apparently provides a complete implementation of cloneable. It is in fact incomplete because it cannot be used on any freestanding type: it requires a derived class to provide meaning, e.g. a declaration using a type cloner<std::string> will not compile.

REFLEXIVE MIX-IN is a particular kind of mix-in, both in that the code has an explicit but decoupled relationship with its derived classes, and in the sense that it is there to provide only implementation and not interface. We might differentiate this latter role by referring to it as a 'mix-imp'.

Template classes are somewhat lacking in explicit constraints on their parameters. This can be seen as both a benefit, allowing the expansive expressive range of generic programming, as well as a liability, such as obscure and unhelpful compiler messages when implied constraints are not observed. It is possible to make some constraints more explicit, as well as adopt naming and syntax usage practices - such as when to use class and when to use typename for a template parameter - that assist the human audience (in truth, the one that really counts) of program source [Henney1996].

All of the creation and deletion of graphic objects in our editor example is handled explicitly by a controller object, i.e. the picture. The same will be true of any other structure that contains and owns graphic objects. Consider the case where we allow users of the editor to create new compound shapes out of other graphic shapes and add them to a library. The basic structure of this is a COMPOSITE^[5] and the means for supporting the creation and extension of a library of such shapes is with a PROTOTYPE [Gamma-1995].

Compound objects strictly own their contents. Assuming that the copy constructor is correctly defined, we can still take advantage of the code automation of the cloner REFLEXIVE MIX-IN. However, we must explicitly manage the details of creation and destruction to ensure correct ownership:

class compound : public graphic, public cloner<compound> { public: compound(const compound &other) { typedef std::list<graphics *>:: const_iterator iterator; for(iterator current = other.graphics.begin(); current != other.graphics.end(); ++current) { graphics.push_back((*current)->clone()); } } virtual ~compound() { for(;!graphics.empty(); graphics.pop_back()) { delete graphics.back(); } } ... private: ... std::list<graphic *> graphics; };

Here the ownership concepts, i.e. creation and deletion, must be managed by explicit control flow and, naturally, careful programming. This code also does not fully reflect our understanding of the constraints: although other.graphics is const in the body of the copy constructor, this constraint does not carry through to its indirectly held contents, i.e. we can still perform non-const operations to change the state of any of other's held graphic objects.

We introduce a QUALIFIED SMART POINTER that in use appears, almost transparently, like a conventional pointer. It retains the level of indirection required to allow its target object to take advantage of inheritance and polymorphism, but asserts ownership and access semantics that make it value-like.

The constructors, destructor and copy assignment operator have been defined to clone and delete their contents as appropriate, ensuring that the lifetimes of the objects and pointer bindings coincide. The member access operators, operator* and operator->, have been overloaded with respect to const-ness so that their results follow the const qualification:

template<class cloneable_type>
class cloning_ptr
{
public:
  cloning_ptr(const cloneable_type *other = 0)
   : body(other ? other->clone() : 0)
  {
  }
  cloning_ptr(const cloning_ptr &other)
   : body(other.body ? other.body->clone():0)
  {
  }
  ~cloning_ptr()
  {
    delete body;
  }
  cloning_ptr &operator=
                    (const cloning_ptr &rhs)
  {
    cloneable_type *old_body = body;
    body = rhs.body ? rhs.body->clone() : 0;
    delete old_body;
     return *this;
  }
  cloneable_type &operator*()
  {
    return *body;
  }
  const cloneable_type &operator*() const
  {
    return *body;
  }
  cloneable_type *operator->()
  {
    return body;
  }
  const cloneable_type *operator->() const
  {
    return body;
  }
  ...
private:
  cloneable_type *body;
};

In use this drastically simplifies our compound class:

class compound : public graphic, public cloner<compound>
{
public:
  compound(const compound &other)
    : graphics(other.graphics)
  {
  }
  virtual ~compound()
  {
  }
  ...
private:
  ...
  std::list< cloning_ptr<graphic> > graphics;
};

The QUALIFIED SMART POINTER is implemented as a template class^[6], allowing any class that supports CLONING through a clone member function to be used. This generalisation clearly accommodates, but does not restrict us to, examples built on the cloneable INTERFACE CLASS. In standard/STL style we can set out the requirements on cloneable_type as follows, assuming that ptr is of type cloneable_type *:

Because there is no exchange of ownership when cloning_ptr is initialised from a cloneable_type *, there are no subtleties with silent conversions from a cloneable_type * to a cloning_ptr and so this constructor can be a converting constructor, i.e. it is not declared explicit. It is a matter of taste as to whether or not you also add user defined conversion operators to support an implicit conversion from a cloning_ptr to a cloneable_type *. More conventionally one would provide get member functions, following the style of std::auto_ptr. Either way, such queries would be overloaded with respect to const-ness and their result type should follow qualification.

The case for get is simple to make as perhaps not all the world works with your framework, and you should be able to get your hands on the owned contents. The case for release is less compelling as the aim of cloning_ptr is to provide an owning pointer and not simply an incidental wrapper for an object, i.e. it won't take ownership of anything passed into it, it will clone it. Consistency suggests that if you want your own pointer to the content you use get, and if you want your own version of it you take an explicit clone yourself. You might wish to introduce release, and perhaps an acquire, if you intend to implement a general grouping construct into which you can add and remove specific graphic objects whilst retaining their identity (classic COMPOSITE). However, beware of mixing ownership models. More generally you can also provide a reset or clear member function.

Further generalisation is also possible using member templates to allow cloning_ptr types that are templated on different parts of a hierarchy to be mixed. This applies to the copy constructor and the assignment operator.

Note that the assignment operator implements COPY BEFORE RELEASE [Henney1997a, Henney1997b, Henney1998a] to preserve the integrity of the object in the event of clone exceptions or self assignment.

QUALIFIED SMART POINTER represents a convergence of many patterns, including SMART POINTER, and therefore PROXY [Gamma-1995] of which it is a specialised form, RESULT TYPE FOLLOWS QUALIFICATION, and COPY BEFORE RELEASE. It also represents a reasonable conclusion to this exploration of polymorphic copying.