Real changes for construction vtables (ignore prior mail)

[Coleen Phillimore]

Martin von Loewis wrote:
> 
> > I was a bit premature.  I needed more forest green.  Attached is the
> > real revision for saving generation of construction vtables.
> 
> Please let me know if I summarise this correctly:
> 
> In a class requiring a VTT, the VTT does not contain the vtables for
> all base subobject, but only for those that require a VTT themselves.
> 
> If that is the intent, how do I interpret the statement
> 
> # Addresses of secondary vtables that either have virtual bases or
> # virtual functions overridden on a virtual path.
> 
> How can they have virtual functions overridden on a virtual path, if
> they don't have virtual bases? I'd think the first condition would be
> sufficient, right?

No.  If you have a class C that overrides a virtual function in a virtual
base class V (but V has no virtual bases itself), C still needs to have
a construction vtable for V.  The construction vtable for V during
construction of C in a more derived class D, may have a different vcall
offset to adjust for the overridden function than C where the most derived
class.  (I think these class names match the example that I provided with
the writeup originally).

> 
> As an aside, I think this new proposal adds quite some complexity by
> requiring a different layout of a vtable group referenced by the VTT
> than a normal vtable group for the complete type (since vtables of
> boring bases are not included in the VTT, but in a normal vtable
> group).

Yes, it does add complexity, which is why I didn't specify it at first.
But the boring class's vtable may add significant storage to the entire
vtable, which is why we decided this proposal was worth looking at.

> 
> Given that difference, I wonder whether the indirection mechanism in
> the VTT is needed at all. Instead of passing a vtable** to the
> not-in-charge ctors, could we not just pass a ctor vtable group?
> I.e. the spec would read

The VTT passed to base classes has the ctor vtable group for the base
class, but it also has the addresses of ctor vtable groups to pass from
the not-in-charge constructor to the constructors of it's base class
(all construction vtables are relative to the most derived class).
Representing it as an array seems the best way to do that.


> 
> The elements of the VTT array are in this order:
> 
>   1. Primary vtable for the complete object.
>   2. For each non-virtual subobject that needs a construction vtable,
>      provide
>       1. Primary construction vtable for the subobject.
>       2. Secondary construction vtables for the subobjects that ...
>   3. Secondary vtables of subobjects that have virtual bases.
>   4. Construction vtables for each virtual subobject in initialization
>      (DFS) order.
> 
> I believe all tables that get concatenated have a well-known size, so
> we do no need the indirection that the VTT provides, do we?

I don't think they do actually, because a construction vtable for a subobject
of a subobject may be at one offset for the complete object and another
for a more derived object.  I'll have to think about this.

Coleen

> 
> Regards,
> Martin

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