11

We know that we can solve the diamond problem using virtual inheritance.

For example:

   class Animal // base class
   {
     int weight;
     public:
     int getWeight() { return weight;};
   };
   class Tiger : public Animal { /* ... */ }; 
   class Lion : public Animal { /* ... */ };
   class Liger : public Tiger, public Lion { /* ... */ }; 
   int main()
   {
     Liger lg ;
     /*COMPILE ERROR, the code below will not get past
     any C++ compiler */
     int weight = lg.getWeight();
   }

When we compile this code we will get an ambiguity error. Now my question is how compiler internally detects this ambiguity problem (diamond problem).

zpasternack
  • 17,838
  • 2
  • 63
  • 81
amod
  • 4,190
  • 10
  • 49
  • 75
  • 1
    Note you are not using virtual inheritance in your code. Your description seems to imply that the example is about solving the diamond problem using virtual inheritance. – K-ballo Sep 12 '11 at 06:07
  • 3
    I up voted you just because the "Liger" made me laugh :-) – selalerer Sep 12 '11 at 06:08
  • 1
    I always thought the diamond problem was printing a diamond to the screen of a given size... took me a minute you meant inheritance conflict... – corsiKa Sep 12 '11 at 06:11
  • K-ballo thats what i commented in code how compiler know this is an error – amod Sep 12 '11 at 07:20
  • 1
    @downvoter... i dont know who voted down this question... please always comment when u do that. – amod Sep 12 '11 at 07:24
  • @selalerer Ligers do exist : http://en.wikipedia.org/wiki/Liger – NWS Sep 12 '11 at 08:59
  • 1
    I posted the source code on ideone: http://ideone.com/iAOsF7 – Anderson Green Mar 10 '13 at 21:32

4 Answers4

5

The compiler builds tables that list all the members of every class, and also has links that allow it to go up and down the inheritance chain for any class.

When it needs to locate a member variable (weight in your example) the compiler starts from the actual class, in your case Liger. It won't find a weight member there, so it then moves one level up to the parent class(es). In this case there are two, so it scans both Tiger and Lion for a member of name weight. There aren't still any hits, so now it needs to go up one more level, but it needs to do it twice, once for each class at this level. This continues until the required member is found at some level of the inheritance tree. If at any given level it finds only one member considering all the multiple inheritance branches everything is good, if it finds two or more members with the required name then it cannot decide which one to pick so it errors.

Miguel Grinberg
  • 65,299
  • 14
  • 133
  • 152
3

When compiler creates a table of function pointers for a class, every symbol must appear in it exactly once. In this example, getWeight appears twice: in Tiger and in Lion (because Liger doesn't implement it, so it goes up the tree to look for it), thus the compiler gets stuck.

It's pretty simple, actually.

littleadv
  • 20,100
  • 2
  • 36
  • 50
  • The error only happens when the method is called, not when the class is defined. The compiler doesn't care if the method name+signature appear twice as long as there's no call to this method. – selalerer Sep 12 '11 at 06:14
  • @sela, true, the compiler ignores methods that are not being called. The compiler only creates the table for methods actually being used. A good compiler, in any case, don't know if it's required per spec. – littleadv Sep 12 '11 at 06:44
  • 1
    -1, compilers usually don't produce tables of function pointers. Especially not "only methods being used". That just doesn't mesh with separate compilation; the set of methods used usually differs per Translation Unit. The closest is the export table in the object files. However, that doesn't contain a `Liger::getWeight` entry. So this doesn't answer the question at all. – MSalters Sep 12 '11 at 09:17
  • @MSalters - I'm not sure you understood what I was saying. Compilers usually do produce tables of function pointers, you probably thought I was referring to a v-table. I was not, I was referring to the compiler's internal structures used when compiling the code. After the code is compiled, if no errors - all functions are represented with a direct function call, but the pointer to this call has to be stored somewhere while the compilation is still in process, wouldn't you agree? Compilers 101. – littleadv Sep 12 '11 at 17:41
  • @litteadv: No, I didn't assume a vtable. I did assume a linker, however, and common object formats. Because you've got separate translation, the compiler does not know where functions will end up. The linker puts in the pointers and resolves function calls. During compilation, methods are represented by their mangled names. And there won't be a mangled name for `Liger::getWeight`. – MSalters Sep 13 '11 at 07:58
  • @Msalters - I'm sure this discussion is totally irrelevant to the OP. We're talking about the same things. – littleadv Sep 13 '11 at 16:53
1

With your code, the structure for liger is

Liger[Tiger[Animal]Lion[Animal]]

If you call an Animal function from a Liger pointer, there are actually two Animal a Liger can convert to (hence the ambiguity)

Virtual inheritance will generate a structure like

Liger[Tiger[*]Lion[Animal]]
            \-----/

There is now just one Animal, indirectly reachable from both of the bases, so a conversion from Liger to Animal is anymore ambiguous.

Emilio Garavaglia
  • 20,229
  • 2
  • 46
  • 63
0

the compiler does not detect the ambiguity problem. the compiler is only interested in the declarations of what is being used in the code. the compiler does not complain if an element is declared more than once.

the ambiguity problem comes from the linker. the linker sees two definitions of the getWeight() function within the inheritance tree of the object lg, and does not know which definition to choose to link with the call lg.getWeight(). so that's the ambiguity.

justastar
  • 123
  • 1
  • 8