VTT clarification

[Mark Mitchell]

>>>>> "Jim" == Jim Dehnert <dehnert at sgi.com> writes:

    Jim> A virtual primary base may move in a further-derived type.
    Jim> Does that matter, i.e. would it change the VTT layout when
    Jim> embedded in a VTT for a more-derived type?

I think that's why the note talks about non-virtual primary bases.  I
think it's precisely the non-virtual primary bases for which we could
(or should) elide secondary vptrs.

Again, I'm afraid we're optimizing rather prematurely.  In particular,
the bit:

    For each subobject X with either (a) virtual bases or (b) virtual
    function declarations overridden along a virtual path between the
    declaration and D, the address of the secondary vtable for X-in-D.

seems a little extreme.  The calculation of how a function is
overridden is non-trivial, increasing the potential for errors and
incompatibilities, all to save a few words in the VTT.  I'm not
confident that's a good tradeoff.

On the one hand, we need to implement this stuff now and see that it
works.  On the other hand, if we're going to simplify these things,
then there's little point in doing the implementation only to remove
it later.  So, it would be good if we resolve this, and the vcall
offset issue I raised yesterday, ASAP.

I apologize for missing last week's meeting -- I know that was a more
appropriate forum for this kind of discussion.

Thanks,

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