In the first box of “simpe hierarchy v2” the line
class clone_inherit : public Base
should be
class clone_inherit : public Base
without the template parameters. The way it’s written here is a syntax error.

In the same box, the body of clone_inherit is written as:
return new Derived(*this);
this should be
return new Derived(static_cast(*this));

Otherwise you get the C2662 error (couldn’t convert clone_inherit to concrete). This conversion is exactly what the static_cast achieves. I found this out by comparing the code to the “full” code on the bottom of the article.

And in the main function (3rd box), the line
std::unique_ptr cc = b->clone();
should be
std::unique_ptr cc = c->clone();

Hi Derp-it,

If I understood directly, you have a hierarchy composed of( for example):

Component -> Drawable -> Sprite

… where Component is abstract (and thus, you expect the clone_impl method to pure virtual) and both Drawable and Sprite are concrete (and thus, you expect clone_impl to be implemented).

My answers are:
1 – It’s possible as is
2 – From a design viewpoint, I humbly advise you to change your hierarchy if it makes sense to you

1 – IT’S POSSIBLE AS IS

The code is already there, all you need is to chose the right parameters. I believe this would suit your needs:

=====================================

class cloneable
: public clone_inherit<abstract_method>
{
};

///////////////////////////////////////////////////////////////////////////////

class component
: public clone_inherit<abstract_method, cloneable>
{
};

///////////////////////////////////////////////////////////////////////////////

class drawable
: public clone_inherit
{
};

///////////////////////////////////////////////////////////////////////////////

class sprite
: public clone_inherit
{
};
=====================================

(Please note WordPress actually messes up any code using lesser-than and greater-than operators, so please ignore the =”” it adds for no reason)

It should work nicely.

(I did not use virtual inheritance because I don’t expect the need, feel free to correct me. Also, I put a base class cloneable, but it is not necessary, you can just make componant not inherit from cloneable, and it should work)

2 – MAKE NON-LEAF CLASSES ABSTRACT

Please note that this is a suggestion unrelated to the article, and even the whole cloneable thing.

It is usually a good design to make sure, in an OO hierarchy, that leaf classes are final (if only in spirit), and that non-leaf classes are abstract (i.e. non-instantiable). The second part will help you avoid class slicing if you happen to use references instead of pointers, or if you happen to dereference your pointers.

So, what I would do with your Hierarchy would be something like, instead of:

Component -> Drawable -> Sprite

… I would have

Component -> AbstractDrawable -> Drawable
and:
Component -> AbstractDrawable -> Sprite

(i.e. Drawable and Sprite are the only concrete classes, and you can’t cast one into another, and both have AbstractDrawable as an abstract parent class, and AbstractDrawable contains all the code for Drawable, Drawable being mostly a shell class)

This will avoid bugs like:

void foo(Drawable & a, Sprite & b)
{
a = b ; // this compiles, and probably produces garbage
}

This will also enable you the rearrange your hierarchy more easily, should you want to introduce intermediary classes between already existing classes.

But that’s a bit out of topic for this article.

I ask because of this use case:

I have a scene graph component system. Various components can be attached to nodes to do different things. I have the following classes (I have more, but this is an example)

Component[Abstract] -> Drawable[Concrete]

Here, Drawable adds the draw methods and will render a set of points held internally via opengl with a supplied material as triangles by default. It’s pretty useful, but the interface is very simplistic so not ideal for more complex concepts. As a result I have some specializations of Drawable (also concrete):

Drawable[Concrete] -> Sprite[Concrete] (This is a specialization of Drawable which supports 9-slicing, or common 4 corner sprite commands, and some specializations of texturing simple box shaped meshes.)

___

Hopefully this example shows a situation where it would be nice to be able to use covariant clone methods with smart pointers on middle-nodes. Ideally both Drawable and Sprite would be clone-able.

Hi Nope,

> What do you achieve by adding “using T::T;” ?
> …
> You also provide link to variadic “using typename … Bases::Bases;”, but I could not figure out what is going on there.

This is to bring all the constructors from the base classes into the current class. The point was to make sure clone_inherit would interfere as little as possible with the “real” user classes.

Thanks,

Correction done.
🙂
Thanks!

Hi Quentin,

Thanks for the comment!
🙂

> Instead of the tag dispatch for the abstract_method, would it make sense to use different class names?

I toyed with a few different ways of specifying if clone_impl had to be pure or not, and in the discussion we had, Jonathan and me, the current one emerged.

For curiosity’s sake, here are the few other candidates:

1 – Using a second parameter in the inheritance:

| class Element : public clone_inherit
| class ComboBox : public clone_inherit

This is arguably ugly, if explicit. It works (it relies on an enum) but, well…

:-/

2 – Using a different name

| class bar : public declare_clone
| class concrete : public implement_clone

While this solution works, I felt it was more complicated because you had two classes, and it is not evident the two actually work together (unless using namespaces, but that’s another problem).

By using a simple name (clone_inherit), my impression is that the reader clearly understands both are the same feature.

3 – Using the same name

This is the solution used for this article:

| class bar : public clone_inherit<abstract_method, etc… >
| class concrete : public clone_inherit

Like I said above, there is no doubt whatsoever that both inheritance rely on the same mechanism, and for me, this is clearly valuable.

The name “abstract_method” could be better, though. It’s always a pain to find a name that isn’t a keyword, but also is short and clear. I can’t remember why I didn’t use “abstract” (this isn’t a C++ keyword, after all).

Another, previous implementation forced the user to tell what they wanted:

| class bar : public clone_inherit<abstract_method, etc… >
| class concrete : public clone_inherit<implemented_method, etc… >

… but there is no real additional value, I believe, as IMHO, the use that happens the more often, and that is the most evident should have less words, the user adding words when they want to move away from the mainstream use. I guess I partially failed that part (I’m open to suggestions/solutions!).

I hope the other parts (showing cool C++ mechanism and providing a solution that asked little or no clutter in the user code) were more successful!
🙂

Thanks!

Hi Colin,

> I’m amazed that in 2017 Visual Studio is still not able to compile valid C++

Indeed, we discovered years ago Visual Studio had a very annoying bug (crash) when mixing virtual inheritance and covariance of the return type on virtual member functions. I’m barely surprised a similar bug (compilation error) appeared for the above code.

This *is* annoying, because it’s a feature that should be considered stable, not “on the edge”.

In the other hand, it is probably barely used, and my perception is that the Visual Studio team is working hard for its compiler to stay relevant in the 21th century, and thus, they have to prioritize. Other compilers are not so lucky.

Thanks,

Hi Colin,

About the typos…

In fact, when rearranging the article one month ago (*), to give it a more “natural, logical” order, and renaming a few symbols, things got mixed up. Indeed, there are three minor typos:
– Two when the destructor is not named after its class (damn copy-paste errors)
– One when “cloneable” is written “clonable”

Rereading the article, I saw the some virtual destructors actually went away when cleaning the original code from its clutter (comments, alternative name, etc.): In the final source, all versions of clone_inherit should have a default virtual destructor.

All this will be corrected as soon as possible.

Thanks!

(*) Jonathan actually puts a massive amount of work on his blog, and his articles are written well in advance their actual publishing.

Apart from that, I’m amazed that in 2017 Visual Studio is still not able to compile valid C++ …