C++ – virtual inheritance

c++inheritancevirtual

What is the meaning of "virtual" inheritance?

I saw the following code, and didn't understand the meaning of the keyword virtual in the following context:

class A {};
class B : public virtual A;

Best Solution

Virtual inheritance is used to solve the DDD problem (Dreadful Diamond on Derivation).

Look at the following example, where you have two classes that inherit from the same base class:

class Base
{

public:

 virtual void  Ambig();

};

class C : public Base
{

public:

//...

};

class D : public Base
{
public:

    //...

};

Now, you want to create a new class that inherits both from C and D classes (which both have inherited the Base::Ambig() function):

class Wrong : public C, public D
{

public:

...

};

While you define the "Wrong" class above, you actually created the DDD (Diamond Derivation problem), because you can't call:

Wrong wrong;
wrong.Ambig();

This is an ambiguous function because it's defined twice:

Wrong::C::Base::Ambig()

And:

Wrong::D::Base::Ambig()

In order to prevent this kind of problem, you should use the virtual inheritance, which will know to refer to the right Ambig() function.

So - define:

class C : public virtual Base

class D : public virtual Base

class Right : public C, public D

Related Solutions

C# – Calling the base constructor in C#

Modify your constructor to the following so that it calls the base class constructor properly:

public class MyExceptionClass : Exception
{
    public MyExceptionClass(string message, string extrainfo) : base(message)
    {
        //other stuff here
    }
}

Note that a constructor is not something that you can call anytime within a method. That's the reason you're getting errors in your call in the constructor body.

Prefer composition over inheritance

Prefer composition over inheritance as it is more malleable / easy to modify later, but do not use a compose-always approach. With composition, it's easy to change behavior on the fly with Dependency Injection / Setters. Inheritance is more rigid as most languages do not allow you to derive from more than one type. So the goose is more or less cooked once you derive from TypeA.

My acid test for the above is:

Does TypeB want to expose the complete interface (all public methods no less) of TypeA such that TypeB can be used where TypeA is expected? Indicates Inheritance.
- e.g. A Cessna biplane will expose the complete interface of an airplane, if not more. So that makes it fit to derive from Airplane.
Does TypeB want only some/part of the behavior exposed by TypeA? Indicates need for Composition.
- e.g. A Bird may need only the fly behavior of an Airplane. In this case, it makes sense to extract it out as an interface / class / both and make it a member of both classes.

Update: Just came back to my answer and it seems now that it is incomplete without a specific mention of Barbara Liskov's Liskov Substitution Principle as a test for 'Should I be inheriting from this type?'

Best Solution

Related Solutions

C# – Calling the base constructor in C#

Prefer composition over inheritance

Related Question