VTT clarification

[Jim Dehnert]

> To: dehnert at sgi.com
> 
> ...
> 
> 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.

At the risk of exhibiting my ignorance (but then you all knew about
that anyway), this doesn't seem so bad.  Each time you process such an
overriding function, you need to know it because you need to generate
the thunk, which references the vcall offset in the virtual base.  If
you simply attach a note to the current class of the virtual base being
overridden (you don't need to remember the function), then the
identification above is done by checking the subobjects for (a) having
virtual bases, or (b) being noted by one of the non-virtual subobjects.

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

Sorry -- not as ASAP as I hoped, but does the above work?

Jim

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