vtable layout

[Jason Merrill]

>>>>> Christophe de Dinechin <ddd at cup.hp.com> writes:

 >>  > And, as I described in an earlier note, the mechanism is totally
 >>  > different when B is a virtual base: In that case, I believe we have
 >>  > to allocate a separate slot for each function in B, otherwise
 >>  > reconvergent (diamond) inheritance can introduce conflicts.
 >> 
 >> Hmm, yes.  Agreed.

 > There is no such problem if it is allocated in the derived class.  
 > There can be multiple slots per virtual base, though (if two sides of  
 > a diamond override the same member), which become unused as soon as  
 > the member is overriden.

The testcase in question is

  struct A {
    virtual void f ();
    virtual void g ();
  };

  struct B: public virtual A {
    void f ();
  };

  struct C: public virtual A {
    void g ();
  };

  struct D: public B, public C { };

Under your scheme, B and C each add a slot to their A vtable.  In D, we
need to fix this up somehow, since they can't both use the same slot.  But
we've already set up B::f and C::g to look in the same place.  So we need a
third-party thunk.

As far as I can tell, the only way to avoid this sort of situation is to
add one slot per virtual function to the A vtable, as Brian suggested.
That way, B would use one, C would use the other, and they would not clash.

Jason