Virtual base class offsets in vtables

[Jim Dehnert]

Mark,

Thanks for continuing to identify sources of confusion.  I've attempted
to fix the questions related to this thread, and have posted the
updated abi-layout.html on the web site.  (There will be more changes
for other issues soon.)  The relevant stuff is in red, and includes
your example.

> From: Mark Mitchell <mark at codesourcery.com>
> 
> Folks --
> 
>   o Why do we have two different ways of computing the order in
>     which vbase offsets are laid out in the vtable?  (Category 3
>     says left to right in declaration order; Category 4 says 
>     in left-to-right depth-first order.)

Unintentional.  It's the same now.

>   o Furthermore, it's unclear whether or not offsets for indirect
>     virtual bases should be stored.  The Category 3 description
>     seems to indicate that only *direct* bases should be stored;
>     otherwise left-to-right declaration order isn't really
>     well-defined.  But, Category 4 clearly says direct or indirect 
>     bases.

Cleaned up.

>   o The term `visible' used in the Category 4 specification is
>     undefined.  This is a bad choice of terminolgy; visibility is
>     used in the C++ standard to contrast with `hidden'.  Here, I
>     think visible is meant to denote classes in the inheritance
>     hierarchy dominated by the base.

"visible" is now gone.


> From: Mark Mitchell <mark at codesourcery.com>
> 
> 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.

My proposed rewriting is that if something is accessible either via a
virtual or a non-virtual base, the first (left-to-right) determines.
It's arbitrary but clear, I think.

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

I believe that the secondary vtables for non-virtual bases are at known
offsets from the derived class vtable.  At least that was once the
intent, if we haven't lost it.  In that case, it's not more expensive
to get at an indirect virtual base -- its offset is always at a known
point, whether negative (direct virtual) or positive (indirect virtual
via non-virtual base).

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

Is what's there now better?  Enough?

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