vtable layout

[Christophe de Dinechin]

> >>>>> thomson  <thomson at ca.ibm.com> writes:
>
>  > Your statement of the rule would have us adding a slot to D's  
vtable,
>  > but in fact that is what we never do, because a D vtable never needs 
>  > an "adjust to D" slot; instead we add slots to (some of) the  
secondary
>  > vtables in a D object.
>
> It seemed simpler to me just to add the slot to D's vtable; since  
we know
> the layout of the vtables, we can find it from any of the  
secondary vptrs.
> But adding it to a secondary vtable from one of D's direct bases  
would also
> work.

I think your initial method would not work: a "convert to D" slot is  
added in D if there is a D::f. It must therefore not conflict with  
any base slot. It can't be computed before all bases are known.

>  > 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.


>  > This work is on a promising path, but I believe we should represent 
>  > it as an "experimental ABI" until it is proven by an implementation. 
>
> That would seem reasonable for the ABI as a whole.

Agreed :-) And there is nothing really new or scary here: we just  
use for all methods what most implementations do for methods in  
virtual bases...

Cheers
Christophe