Virtual base class offsets in vtables

Mark Mitchell mark at codesourcery.com
Tue Jan 18 23:02:14 UTC 2000


>>>>> "Jason" == Jason Merrill <jason at cygnus.com> writes:

    Jason> Not exactly; we only have entries for indirect virtual base
    Jason> classes that are reached through another virtual base.

OK -- I see.  So, to find an indirect virtual base that is not reached
through another virtual base, we first convert though non-virtual
bases until we reach the point where the virtual base is a direct
base; then we use the vbase offset that we can find in the vtable for
that base.

What about:

  struct S { };
  struct T : virtual public S {};
  struct U : virtual public T {};
  struct V : public T, virtual public U {};

Do we have a vbase offset in `V' for `S'?  It's reachable by
non-virtual inheritance as the direct base of `T', but it is also
reachable through a virtual base.  The sentence quoted above would
seem to suggest that we do have a vbase offset for it -- but that
doesn't make a lot of sense given that we wouldn't were `U' entirely
out of the picture.

I'm not sure I think this degree of complexity is a good idea.  The
chances of misimplementing the ABI (and thereby making it less
valuable) increase with each bit of complexity.  

And, entries in vtables are very cheap -- that's the motivation for
putting the vbase entries there in the first place.  Why make it more
expensive to convert to an indirect virtual base than a direct virtual
base, just to save a few entries in the statically initialized vtable?
Or, conversely, why put *any* entries for indirect vbases in the
vtable when you could always just walk a path to the vbase, even if
doing so required going through several other vbases?  Why is this the
right tradeoff?

In any case, such analysis aside, would you mind writing up a more
rigorous description of the scheme that's been decided upon?  That
description will make it much easier to make sure that we're all
getting this stuff right.

Thanks again for your help,

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




More information about the cxx-abi-dev mailing list