Vcall offsets

[Mark Mitchell]

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.

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.

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com