Vtables

[Coleen Phillimore]

Mark Mitchell wrote:
> 
> >>>>> "Coleen" == Coleen Phillimore <coleen at zko.dec.com> writes:
> 
>     Coleen> In the construction vtables section, I suggested the same
>     Coleen> ordering as #7 for nonvirtual bases at least, since
> 
> What's #7?  I'm somehow not understanding what in the documents that's
> a cross-reference to.

The 7 was from your original mail that referred to the statement you
were quoting about the order of secondary vtables in the ABI data layout
document (under "Virtual Table Order").

> 
>     Coleen> there's a one-to-one relationship between vptrs and
>     Coleen> vtables for a derived class.  If two bases are at the same
>     Coleen> offset, they share the same vtable.
> 
> True.
> 
>     Coleen> The trouble that I have with the left-to-right wording is
>     Coleen> that if you have an nearly empty virtual base class that
>     Coleen> shares a vptr with a subobject in the class, the vtable
>     Coleen> would be coincident with the shared subobject vtable, and
>     Coleen> not allocated at the end of the vtable array (in it's
>     Coleen> left-to-right position).  Just like in the base class
>     Coleen> layout algorithm itself.
> 
> I've just implemented the vtable combination stuff in GCC.  Here's how
> it works:

I'm about to implement this myself and this is probably the algorithm
I will use as well.  It seems to be the same as the algorithm for
laying out base classes, except that the non-shared virtual vtables
should be last.

The non-virtual set of vtables needs to be first in the "fixed" part of
the greater vtable (for construction vtables to work properly), and the
vtables for virtual parts later.

I agree we need more specification of the ordering, which is why I tried
to do so in the construction vtable section.  Can you look at that?  Do you
think that should be reworded as a walk of the base classes not their
offsets too?

Thanks,
Coleen

> 
>   o Do a depth-first, left-to-right walk of the graph.  Never walk
>     the same node twice.
> 
>   o As you visit each node, if it is not a primary base, and has
>     a vptr, add its vtable.
> 
> I'm not sure if that's what you meant.  With this algorithm, the
> primary vtable is automatically output first, and there are no extra
> vtables output.
> 
> I don't really care what order we pick, but it needs to be clearly
> specified.  It's also advantageous if these things can be computed
> relatively independently of each other.  For example, the algorithm I
> just outlined can be implemented if you have the inheritance graph,
> and bits saying which things are primary bases, without knowing the
> offsets of the various bases, how various things got to be primary,
> etc.  That's nice in that changes to the ABI, or supporting other
> similar ABIs, will be easy -- there aren't too many interdependencies.
> 
> --
> Mark Mitchell                   mark at codesourcery.com
> CodeSourcery, LLC               http://www.codesourcery.com

-- 
-----------------------------------------------------------------------
Coleen Phillimore                  | mailto:coleen at zko.dec.com
Compaq Computer Corp.   Nashua, NH | COMPAQ C++ Compiler Development
-----------------------------------------------------------------------