Vcall offsets

[Jim Dehnert]

Once again, I'll take a shot at this one, but please correct my
misconceptions.

> From: Mark Mitchell <mark at codesourcery.com>
> 
> We have:
> 
>   [T]he vtable for a virtual base A also includes a vcall offset entry
>   for each virtual function represented in A's primary vtable and the
>   secondary vtables from A's non-virtual bases.  The vcall offset
>   entries are allocated from the inside out, in the the same order as
>   the functions appear in A's vtables.
> 
> Now consider this hierarchy:
> 
>     struct A {
>       int i;
>       virtual void f ();
>     };
> 
>     struct B {
>       int j;
>       virtual void g ();
>       virtual void h ();
>     };
> 
>     struct C : public A, public B {
>       virtual void g ();
>     };
> 
> Assume that C is being used as a virtual base.  The question is what
> vcall offsets are present in C and in what order.  Note that A is the
> primary base of C.
> 
> One reading of the paragraph quoted above could lead one to conclude
> that C contains 4 vcall offsets:
> 
>   o One for `A::f' - A::f appears in C's primary vtable
>   o One for `B::g' - B::g appears in the secondary vtable for B
>   o One for `B::h' - B::h appears in the secondary vtable for B
>   o One for `B::g' - B::g appears in C's primary vtable
> 
> I think we should make clear that the last one is not required.  Even
> though the vtable entry for B::g is replicated, there's no reason to
> replicate the vcall offset.

I agree with your objective, but would come to a different interpretation.
I would state the rule for what's included as follows:

 1) First, whatever's required by the primary base class.

 2) Next, anything additional (not overrides of the primary base) from
    the class being laid out.

 3) Finally, anything additional from the base classes, in declaration
    preorder for the bases, declaration order for the functions within
    the bases.

So, I think we need a vcall offset for C::g (2) but not for B::g (3).
Not a functional difference, but it affects the ordering.

> On to the order of the three remaining entries.  The A::f entry must
> go closest to the vptr, since A is a primary base.  (It would actually
> work, here, without that consideration since A is not a primary
> *virtual* base, but the current document doesn't distinguish these
> cases and there's no reason why it should.)  Is the final order:
> 
>   B::g
>   B::h
>   A::f
>   
> or:
> 
>   B::h
>   B::g
>   A::f
> 
> ?  "From the inside out" isn't too helpful.  I don't think this
> matters at all -- except we have to decide.  I like the second order
> better, I think.

So, applying the above rule, I would get (with the rule number in
parentheses):

	B::h  (3)
	C::g  (2)
	A::f  (1)

I'll try to clarify this rule (or whatever other concensus emerges) in
the document.  Please comment if this doesn't match your understanding.

Jim

-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272