Make a standard gemstone inheritance. Class A defines pure virtual function forex, class B defines implementation for forex, classes C and D do nothing at all with forex. When attemping to call forex on demonstration of class D you will get 'ambiguous function call' error although there's just one implementation of forex. This is often solved by B and C getting from the in virtual manner. Could it be a correct solution for that problem? How exacly does virtual inheritance handle merging of virtual function tables?



Thanks! Martin

... Note, Plant Sutter authored 3 excellent articles about multiple inheritance (1) here, (2) here and (3) here . He authored an entire other couple of helpful articles in guru-of-the-week here. Highly suggested ...

First, i am unsure which i get a hierarchy right. I'm guessing it is just like this:

struct A 

struct B : A  

struct C : A 

struct D : B, C 

Well, D is abstract, because you will find two A subobjects within an object of type D: One that's made concrete by B with the lattice of B, and something that's still abstract within the lattice dealing with C. I'm guessing you've got a pointer to D and then try to call F. Yes, an ambiguity arises, since the compiler finds two functions F in 2 separate lattices:

D -> B::F

D -> C -> A::F

Searching such as this:

    F()   F()

     A     A


 F() B     C



You are able to fix that situation formally by drawing from the virtually:

struct B : virtual A  

struct C : virtual A 

struct D : B, C 

After this you have this case, known as gemstone inheritance:




 F() B     C



And doing the research, it finds that there's B::F overriding A::F. Although A::F can nonetheless be arrived at through D::C::A, that's no ambiguity any longer, because A was inherited virtual.

Whether this is actually the correct solution inside your particular problem - that's absolutely not certain. You will find most frequently possible ways than drawing virtual from the class. For your question about merging of virtual function tables - that's completely with respect to the implementation. GCC, so far as i understand, could keep a pointer towards the one A instance within the virtual table of D, as we derive virtual.

Could it be a correct solution for that problem?

"Gemstone" inheritance is problematic, and also the correct explanation from the solution takes a little of explaining. I suggest you browse the following sections of Meyers' Effective C++:

  • Item 26, Guard against potential ambiguity
  • Item 43, Use multiple inheritance sensibly.