Real changes for construction vtables (ignore prior mail)

[Martin von Loewis]

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

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

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

Regards,
Martin