Talk:More C++ Idioms/Interface Class

Virtual Inheritance of interfaces: By default?
Shouldn't the class that implements the interface use public virtual inheritance to prevent the diamond problem with multiple inheritance of the same interface?

-- Howard.

Hlovatt (discuss • contribs) 08:09, 28 April 2014 (UTC)

Not always, IMHO. In the example of the Capability Query, I would not inherit virtually from Shape, because it is the root class of the "shapes" hierarchy. But I would inherit virtually from the Rollable class, because it is independant from the hierarchy

See my question on StackOverflow: https://stackoverflow.com/questions/20327894/virtual-inheritance-use

--Paercebal (discuss • contribs) 21:54, 10 September 2014 (UTC)

Default generated methods
The current Shape implementation on this Interface Class idiom is easy to misuse:

To prevent that, we would need to make the operator = either protected or private.

A private copy assignment would make it impossible to use the default operator = for a derived concrete class:

Shape is an interface describing what is a shape. Unless by explicit design, it shouldn't impose the copy-assignability of its deriving types.

So in the end, having for a Shape a protected default copy-assignment is the solution: You can't have slicing (or in the case above, a no-op that this compiles) because the copy-assignment is protected, and at the same time, Circle is a value type which is happy with its default copy-assignment.

Everyone wins.

Conclusion: At the very least, I would declare a protected default assignment. To make this simpler, I have at work a macro that goes something like this:

This way, we can inherit from Shape, and still have natural value-type behavior for inheriting classes. We can then choose freely their implementation details without interference from the interface.

In C++11, the constructors/destructors/operators in the macro would be marked as default, of course.