Virtual inheritance

Virtual inheritance is a C++ technique that ensures only one copy of a base classs member variables are inherited by grandchild derived classes. Without virtual inheritance, if two classes codice_1 and codice_2 inherit from a class codice_3, and a class codice_4 inherits from both codice_1 and codice_2, then codice_4 will contain two copies of codice_3s member variables: one via codice_1, and one via codice_2. These will be accessible independently, using scope resolution.
Instead, if classes codice_1 and codice_2 inherit virtually from class codice_3, then objects of class codice_4 will contain only one set of the member variables from class codice_3.
This feature is most useful for multiple inheritance, as it makes the virtual base a common subobject for the deriving class and all classes that are derived from it. This can be used to avoid the diamond problem by clarifying ambiguity over which ancestor class to use, as from the perspective of the deriving class (codice_4 in the example above) the virtual base (codice_3) acts as though it were the direct base class of codice_4, not a class derived indirectly through a base (codice_1 or codice_2).
It is used when inheritance represents restriction of a set rather than composition of parts. In C++, a base class intended to be common throughout the hierarchy is denoted as virtual with the codice_21 keyword.
Consider the following class hierarchy.
struct Animal {
 virtual ~Animal() = default;
struct Mammal: Animal {
struct WingedAnimal: Animal {
// A bat is a winged mammal
struct Bat: Mammal, WingedAnimal {};
Bat bat;
As declared above, a call to codice_22 is ambiguous because there are two codice_23 (indirect) base classes in codice_24, so any codice_24 object has two different codice_23 base class subobjects. So an attempt to directly bind a reference to the codice_23 subobject of a codice_24 object would fail, since the binding is inherently ambiguous:
Bat b;
Animal&amp; a = b; // error: which Animal subobject should a Bat cast into, 
 // a Mammal::Animal or a WingedAnimal::Animal?
To disambiguate, one would have to explicitly convert codice_29 to either base class subobject: 
Bat b;
Animal&amp; mammal = static_cast&lt;Mammal&amp;&gt;(b); 
Animal&amp; winged = static_cast&lt;WingedAnimal&amp;&gt;(b); 
In order to call codice_30, the same disambiguation, or explicit qualification is needed: codice_31 or codice_32 or alternatively codice_33 and codice_34. Explicit qualification not only uses an easier, uniform syntax for both pointers and objects but also allows for static dispatch, so it would arguably be the preferable method.
In this case, the double inheritance of codice_23 is probably unwanted, as we want to model that the relation (codice_24 is an codice_23) exists only once; that a codice_24 is a codice_39 and is a codice_40 does not imply that it is an codice_23 twice: an codice_23 base class corresponds to a contract that codice_24 implements (the "is a" relationship above really means ""implements the requirements of"), and a codice_24 only implements the codice_23 contract once. The real world meaning of "is a" only once" is that codice_24 should have only one way of implementing codice_30, not two different ways, depending on whether the codice_39 view of the codice_24 is eating, or the codice_40 view of the codice_24. (In the first code example we see that codice_30 is not overridden in either codice_39 or codice_40, so the two codice_23 subobjects will actually behave the same, but this is just a degenerate case, and that does not make a difference from the C++ point of view.)
This situation is sometimes referred to as diamond inheritance (see Diamond problem) because the inheritance diagram is in the shape of a diamond. Virtual inheritance can help to solve this problem.
The solution.
We can re-declare our classes as follows:
struct Animal {
 virtual ~Animal() = default;
// Two classes virtually inheriting Animal:
struct Mammal: virtual Animal {
struct WingedAnimal: virtual Animal {
// A bat is still a winged mammal
struct Bat: Mammal, WingedAnimal {};
The codice_23 portion of codice_57 is now the "same" codice_23 instance as the one used by codice_59, which is to say that a codice_24 has only one, shared, codice_23 instance in its representation and so a call to codice_62 is unambiguous. Additionally, a direct cast from codice_24 to codice_23 is also unambiguous, now that there exists only one codice_23 instance which codice_24 could be converted to.
The ability to share a single instance of the codice_23 parent between codice_39 and codice_40 is enabled by recording the memory offset between the codice_39 or codice_40 members and those of the base codice_23 within the derived class. However this offset can in the general case only be known at runtime, thus codice_24 must become (codice_74, codice_39, codice_74, codice_40, codice_24, codice_23). There are two vtable pointers, one per inheritance hierarchy that virtually inherits codice_23. In this example, one for codice_39 and one for codice_40. The object size has therefore increased by two pointers, but now there is only one codice_23 and no ambiguity. All objects of type codice_24 will use the same vpointers, but each codice_24 object will contain its own unique codice_23 object. If another class inherits from codice_39, such as codice_88, then the vpointer in the codice_39 part of codice_88 will generally be different to the vpointer in the codice_39 part of codice_24 though they may happen to be the same if the codice_88 class be the same size as codice_24.
Additional Example of Several Ancestors.
This example to illustrates a case where base class codice_3 has a constructor variable codice_96 and an additional ancestor codice_97 is derived from grandchild class codice_4. 
Here, codice_3 must be constructed in both codice_4 and codice_97. Further, inspection of the variable codice_96 illustrates how class codice_3 becomes a direct base class of its deriving class, as opposed to a base class of any intermediate deriving classed between codice_3 and the final deriving class. The code below may be explored interactively here.
class A { 
 private: 
 std::string _msg; 
 public:
 A(std::string x): _msg(x) {} 
// B,C inherit A virtually
class B: virtual public A { public: B(std::string x):A("b"){} };
class C: virtual public A { public: C(std::string x):A("c"){} };
// Compile error when :A("c") is removed (since A's constructor is not called)
//class C: virtual public A { public: C(std::string x){} };
//class C: virtual public A { public: C(std::string x){ A("c"); } }; // Same compile error
// Since B, C inherit A virtually, A must be constructed in each child
class D: public B,C { public: D(std::string x):A("d_a"),B("d_b"),C("d_c"){} }; 
class E: public D { public: E(std::string x):A("e_a"),D("e_d"){} }; 
// Compile error without constructing A
//class D: public B,C { public: D(std::string x):B(x),C(x){} };
// Compile error without constructing A
//class E: public D { public: E(std::string x):D(x){} };
int main(int argc, char ** argv){
 D d("d"); 
 d.test(); // hello from A: d_a
 E e("e"); 
 e.test(); // hello from A: e_a
Pure Virtual Methods.
Suppose a pure virtual method is defined in the base class. If a deriving class inherits the base class virtually, then the pure virtual method does not need to be defined in that deriving class. However, if the deriving class does not inherit the base class virtually, then all virtual methods must be defined. The code below may be explored interactively here.
class A { 
 protected: 
 std::string _msg; 
 public:
 A(std::string x): _msg(x) {} 
 void test(){ std::cout«"hello from A: "«_msg «"\n"; } 
 virtual void pure_virtual_test() = 0;
// since B,C inherit A virtually, the pure virtual method pure_virtual_test doesn't need to be defined
class B: virtual public A { public: B(std::string x):A("b"){} }; 
class C: virtual public A { public: C(std::string x):A("c"){} }; 
// since B,C inherit A virtually, A must be constructed in each child
// however, since D does not inherit B,C virtually, the pure virtual method in A *must be defined*
class D: public B,C { 
 public: 
// it is not necessary to redefine the pure virtual method after the parent defines it
class E: public D { 
 public: 
 E(std::string x):A("e_a"),D("e_d"){} 
int main(int argc, char ** argv){
 D d("d");
 d.test(); // hello from A: d_a
 d.pure_virtual_test(); // pure virtual hello from: d_a
 E e("e"); 
 e.test(); // hello from A: e_a
 e.pure_virtual_test(); // pure virtual hello from: e_a