Virtual base alignment

[Jim Dehnert]

I've added this comment to the A-17 issue.  A couple of observations
though:

1) A similar discussion occurred w.r.t. the choice of a non-virtual
primary base class, and the decision to use strict declaration order
rather than attempting to optimize was based on the desire to allow a
programmer to make the choice, whether optimal or not.

This is not quite the same situation -- at least I can't come up with
convincing cases where Mark's proposal would be worse, but that angle
should be considered.

2) Mark's proposal affects I-2a as well as III.

Jim

> From: Mark Mitchell <mark at codesourcery.com>
> Date: Sun, 02 Jan 2000 22:12:58 -0800
> 
> I think the current proposal for allocating virtual bases is still a
> little suboptimal.  In particular, given:
> 
>   struct A { void f(); };
>   struct B : virtual public A {};
>   struct C : virtual public A, virtual public B {};
> 
> we'll give `C' a larger size than for:
> 
>   struct C : virtual public B, virtual public A {};
> 
> where we'll reuse the `A' part of `B' rather than reallocating it.
>   
> I know that ordering can already affect size (principally because of
> alignment issues) but I think that in this case we might as well not
> punish programmers for choosing the "wrong" ordering.
> 
> I think we should change the green A-17 proposed resolution to
> indicate that if one of the virtual bases is a (direct or indirect)
> primary base of one of the other virtual bases then we need not
> allocate a fresh copy.
> 
> FWIW, it turns out to actually be easier in GCC to code the more
> generous version.
> 
> The algorithm to do this is linear in the size of the hierarchy: just
> iterate through the inheritance DAG marking all primary bases.  Any
> virtual base classes that remain unmarked need to be allocated in step
> III.  A slight formalization of this sentence might be a good way to
> express which bases to choose for III.

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