Vtables

[Mark Mitchell]

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

    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:

  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