You can’t just use new Vehicle in this situation because only the base class elements (those from the Vehicle base class) will be available in the copy. So what do we do?

Polymorphic cloning

The solution is to use the commonly-used polymorphic cloning pattern. In this pattern, we define a virtual function – which we’ll call clone() in this article – which when called via an object pointer returns a new object of the correct derived type. For this to work, each derived type must override clone() and return a copy of itself, like this:

You can now clone an object which is a derived type of Vehicle like this:

Vehicle *copy_of_vehicle = vehicle_to_copy->clone();

Assuming your objects have appropriately defined copy constructors, this will allocate memory on the heap for a new object of the correct derived type and execute the copy constructor to copy the data into the new object. The following code is a full working example:

This pattern takes advantage of the fact that when a virtual function in a base class which returns an object of the class’s type is overridden by a derived class, the return type can be changed to that of the derived object’s class type. This is called co-variant return types. Eg. when you define the virtual clone() function in Vehicle as returning an object of type Vehicle, you can override the function in the derived class Plane to return an object of type Plane, and this is not a violation of C++’s strong typing rules. As you can see, the implementation of clone() is essentially the same in each derived class. This is slightly awkward, and – if you have many derived classes – makes the code messier and more error-prone if you forget to implement clone() or copy-paste without changing the object type. What if there was a way to provide the clone() function automatically in each derived type?

The Curiously Recurring Template Pattern (CRTP)

The CRTP is a pattern which has many applications, but its main feature is that you can define a class which derives from a template class where the class being defined is itself a template type parameter. For example, if you have a template class MyTemplateClass and you want to define a class called SomeClass, the following code is valid:

class SomeClass : public MyTemplateClass<SomeClass>

What does this do for us? Well, it means that any function we include in the template class which uses the template type parameter will be duplicated in all the derived classes which use it, with the type name replaced by the name of the class we are defining. Consider the following code:

In Vehicle, we define the interface that each derived type must implement, namely clone() and describe() in this case, as in the original polymorphic cloning example. In VehicleCloneable, we drive from Vehicle and implement the clone() function using the template type parameter Derived to create an object of the type specified when we define each class which derives from VehicleCloneable. The static_cast is required because *this will reference an object of type VehicleCloneable by default, so we need to down-cast to the correct derived type. Now we can re-implement the other vehicles as follows:

As you can see, each class definition derives from VehicleCloneable using its own type name as the template type parameter. This will cause VehicleCloneable<DerivedVehicleType>::clone() to be inherited by each new derived class. The code in main() remains the same, as does the output.

This works fine as long as we are only using one level of derivation, but what if we want to derive from an already-derived class like this:

class FighterPlane : public Plane

How do we convert this definition to use the CRTP?

class FighterPlane : public VehicleCloneable<????>

Now we have a problem. If we derive from VehicleCloneable<Plane>, the implementation of clone() will return the wrong type – Plane instead of FighterPlane. If we derive from VehicleCloneable<FighterPlane>, we won’t inherit the fields and methods from Plane.

CRTP with Multi-Level Inheritance

To work around this, we have to get creative. We need to supply two template parameters to VehicleCloneable: the type name of the class being defined as we currently use, but also the type name of the class we want to derive from. We re-write VehicleCloneable as follows:

The key here is that whereas VehicleCloneable used to derive from Vehicle, it now derives from the template type parameter Base, which ensures the proper inheritance of Base‘s fields and methods. We also change the return type of clone() from Vehicle * to Base *, to ensure that a pointer to the correct parent class is returned. We now re-write the definitions of Car and Plane as follows:

The constructor forwarding problem

the individual derived classes only use constructors which don’t call any base constructors

Most of the time though in a real world application, the derived classes will have multiple constructors with different signatures, and oftentimes you will want to call a base constructor too. In these cases, you will experience the constructor forwarding problem. Consider the following re-work of the above code:

We have given the Vehicle class a fuelCapacity, the Plane class a wingSpan (and the constructor also passes the fuel capacity back to Vehicle), and the FighterPlane class (which is itself derived indirectly from Plane via the CRTP middle-man class VehicleCloneable) a numberOfBombs, and again this classes passes back the fuel capacity and wing span to Plane.

To simplify calling of the base constructor, we define a private typedef in each derived class specifying the templated base class to refer to (called BaseClass).

You might at first glance think this should work nicely, but unfortunately it won’t compile. The problem comes with the fact that the base class constructors being called are all expected to be in VehicleCloneable<…>, not the ‘conceptual’ base classes we want. Adding in the middle-man class distorts the inheritance hierarchy such that the constructor calls can’t be forwarded to the conceptual base classes directly, only via VehicleCloneable.

What if we try to just reference the conceptual base classes directly in our base constructor calls, eg. Vehicle from Car and Plane from FighterPlane? Unfortunately, since we haven’t derived directly from these – rather from VehicleCloneable – the compiler will emit an error saying that the class being referenced in the base constructor call is not a base class.

A horrible workaround

NOTE: The following is just for illustration and should not be used in real applications.

What the compiler is expecting is a bunch of constructors in VehicleCloneable, using every possible set of signatures that all of the derived classes use. The following will compile:

While this works, it is obviously a terrible solution because every time we add a new derived class, or a new constructor to an existing derived class, we have to add a new forwarding constructor with the same signature to VehicleCloneable.

The C++11 solution

If you are using a C++11 compiler which supports constructor inheritance (that includes gcc and clang, but not Visual Studio 2012 or 2013), the solution is trivial and one line long:

The using line causes all constructors to be automatically inherited from whichever base class is specified in the Base template type parameter, bringing them into whatever specialization of VehicleCloneable we are currently deriving from. To illustrate further, if you have the following base class:

The using declaration creates a series of new constructors in MyDerived with matching signatures to those in MyBase, simply passing all the arguments to the MyBase constructors and doing nothing else (empty function body). This is the essence of constructor forwarding.

Side Note: As noted by Tim in the comments, in C++11 it is generally preferred to return a std::unique_ptr rather than a naked (unwrapped) pointer from a function. The above code is purely for illustrative purposes.

The C++03 solution

No such luxuries exist in prior versions of C++, and even though solutions exist, they are not entirely transparent as they require syntactical changes to the way your constructors are defined. The most thorough solution is to create a series of templates with varying numbers of type parameters; these act as argument containers whose types can be anything, and can then be passed around in derived and base constructors which all have a unified signature: a single argument whose type is the same as the template used to hold the real arguments. Hence the required syntactical changes to the way you create your constructors.

Is it all worth it? Ah screw it, let’s just cheat with macros

We have taken a number of detours to solve the basic problem of allowing polymorphic cloning without having to type in the clone() function, and you have to ask yourself if all the hassle is really worth the effort. The answer depends on your application, but in most cases, probably not when you consider all the downsides. So let’s go back to basics.

C++ macros in the 21st century. Not my first choice for easy-to-maintain code, but in this case, it may be worth it.

In C++11, even on Visual Studio and gcc 4.6 (before inherited constructors was implemented), you could just do perfect forwarding with variadic templates. Not nearly as simple as inherited constructors, but definitely beats macros…

Yeah I did have that in mind actually, it was the one version I didn’t bother to the article. You caught me 🙂 The main reason I didn’t is essentially because that’s a ‘fudge’ for partially C++11 compliant compilers, the true C++11 inheriting constructor solution is simple as you said, and those with no C+11 support can’t use variadic templates anyway, as you know.

This sort of CRTP use (the last examples before your macro cases) is perhaps one of the primary arguements for mixins in C++: the ability to inject virtual method override implementations into a class without introducing multiple inheritance or diamond inheritance. The CRTP pattern gets ugly when you want to mix in more than one template and the only remaining visable option in that case is macros, which in theory we’re trying to stop using as a community.

As you can see, WordPress is hideous when it comes to source code 😦 You need to enclose it in [ sourcecode lang=”cpp” ] (without the spaces near the brackets) I think. Even when I am writing articles, it loves to remove anything inside chevrons randomly, I’m forever going back over pasted source code with templates or #includes in…

nonetheless, I got the idea so hopefully others will too, thanks very much for taking the time to post! 🙂

I like the idea and the C++11 version is a great solution.
But I hate the bad examples … junior programmer will copy past these code fragments and then they will introduce bugs.
Polymorphic base classes must always have a public virtual destructor or a protected destructor one.
Don’t return naked pointers in C++11. The idiom here is to return a std::unique_ptr unless you want to have covariant returns types.

I’m aware of these things, I tried to just make the examples bare bones without any distractions, and when it concerns returning a pointer, the patterns in the article don’t just apply to C++11. Maybe I should have added in a virtual destructor though.

The virtual destructor is not clutter is just plain correctness that many programmers still forget. I can follow you about the pointer but personally I would mention it in the C++11 section so people pick it up these new idioms.

Hi,
Sorry to reply bit late, just read this post when searching for CRTP.
Very nicely written, it as easy to understand and could write code myself to see how it works.
Just a question, for curiosity I thought of deleting all the memory allocated using new keyword and this is what i tried in main function at end.
delete car;
delete plane;
delete fighterplane;
delete vehicleUnknown;
Surprisingly the binary crashed with segmentation fault. I am using gcc 4.7 .
i checked the address for each pointer and saw plane and vehicleUnknown are pointing to same memory address. Why should it do so? Please help

Notice that FighterPlane can (and is actually expected to) initialize Plane directly just as if it was inheriting from it. This is usually an annoying (and sometimes dangerous) side-effect of virtual inheritance, but in this case it actually helps. All compiles fine with Visual Studio 2012 and the example runs with expected results:

No need to redefine clone() in each derived class, no macros and no contrived constructor modifications!

Hello Katy, thanks for your explanation. However, I would like to ask you about something I didn’t understand well. Instead of the clone method, why can’t we proceed like this: I define a pointer with

Vehicle* pt = new Plane;

And then, in the main just write

pt->describe();

? Would that be a legitimate alternative to the clone method? I obtain the same output, and it looks like the same kind of situation, so why is the clone method necessary after all?
Thanks, great blog!

Base’s copy constructor or some structure in between somehow knows that it is about creating clone of Derived and call is forwarded to copy constructor of Derived or other derived class without manual determining of exact type and dispatching constructor call.

I saw some tricks (ACCU) of how to walk by inheritance road in opposite direction by using CRTP, but nothing related to constructors’ forwarding was there.