Tuesday 4 December 2012

Virtual Inheritance and Diamond Problem in C++

Multiple inheritance in C++ is a powerful, but tricky tool, that often leads to problems if not used carefully. One of the major problem that arises due to multiple inheritance is the diamond problem.

The "diamond problem" (sometimes referred to as the "deadly diamond of death") is an ambiguity that arises when two classes B and C inherit from A, and class D inherits from both B and C. If D calls a method defined in A (and does not override the method), and B and C have overridden that method differently, then from which class does it inherit: B, or C?

                         Class A
                       ____|____
                      /                 \  
               Class B         Class C 
                      \________ /    
                               |
                         Class D

Classic Example:

class Animal {
 public:
  virtual void eat();
};
 
class Mammal : public Animal {
 public:
  virtual void breathe();
};
 
class WingedAnimal : public Animal {
 public:
  virtual void flap();
};
 
// A bat is a winged mammal
class Bat : public Mammal, public WingedAnimal {
};
 
Bat bat;

As declared above, a call to bat.eat() is ambiguous because there are two Animal (indirect) base classes in Bat, so any Bat object has two different Animal base class sub-objects. So an attempt to directly bind a reference to the Animal sub-object of a Bat object would fail, since the binding is inherently ambiguous:

Bat b;
Animal &a = b; // error: which Animal subobject should a Bat cast into, 
               // a Mammal::Animal or a WingedAnimal::Animal?

Solution is in Virtual Inheritance:

And our re-implemented class looks like this,

class Animal {
 public:
  virtual void eat();
};
 
// Two classes virtually inheriting Animal:
class Mammal : public virtual Animal {
 public:
  virtual void breathe();
};
 
class WingedAnimal : public virtual Animal {
 public:
  virtual void flap();
};
 
// A bat is still a winged mammal
class Bat : public Mammal, public WingedAnimal {
};


The Animal portion of Bat::WingedAnimal is now the same Animal instance as the one used by Bat::Mammal, which is to say that a Bat has only one, shared, Animal instance in its representation and so a call to Bat::eat() is unambiguous. Additionally, a direct cast from Bat to Animal is also unambiguous, now that there exists only one Animal instance which Bat could be converted to.

This is implemented by providing Mammal and WingedAnimal with a vtable pointer (or "vpointer") since the memory offset between the beginning of a Mammal and of its Animal part is unknown until runtime. Thus Bat becomes (vpointer, Mammal, vpointer, WingedAnimal, Bat, Animal). There are two vtable pointers, one per inheritance hierarchy that virtually inherits Animal. In this example, one for Mammal and one for WingedAnimal. The object size has therefore increased by two pointers, but now there is only one Animal and no ambiguity. All objects of type Bat will have the same vpointers, but each Bat object will contain its own unique Animal object. If another class inherits from Mammal, such as Squirrel, then the vpointer in the Mammal object in a Squirrelwill be different from the vpointer in the Mammal object in a Bat, although they can still be essentially the same in the special case that the Squirrel part of the object has the same size as the Batpart, because then the distance from the Mammal to the Animal part is the same. The vtables are not really the same, but all essential information in them (the distance) is.

No comments:

Post a Comment