Empty base optimization, sharing vptrs

[Michael Ball]

>The major assumption I'm making about class layout is that we're accessing
>virtual bases through an offset in the vtable rather than through a pointer
>in the class itself, so the only hidden member in an object is its vptr.
>
>NONPOLYMORPHIC BASES

I am assuming by this that you mean that the base class itself is
non-polymorphic.  That is, it has no virtual functions and no virtual
bases.

>
>We may allocate any number of empty base subobjects at the same location
>(the beginning of the complete object) except when, because of repeated
>inheritance, we'd have multiple subobjects of the same type allocated in
>the same place.

Check

>
>NON-VIRTUAL POLYMORPHIC BASES
>
>The first immediate base subobject (not necessarily the leftmost
>immediate base, since we're allowed to reorder base classes) may share
>its vptr with the complete object.  We may allocate any number of
>non-virtual polymorphic base subobjects at offset zero, provided that
>all but one are empty except for their vptrs and that none of these
>base classes have any non-virtual base classes in common themselves.
>(It's OK if they do have virtual bases in common.)

I don't see how you can allocate more than one immediate polymorphic
bases at offset 0, they will in general require different vtables since
they will have different virtual functions.  If by empty you also
imply that they have no virtual functions of their own, then OK, they
can be ignored and only their bases matter.  Normally I would think
that empty implied only a lack of data members.

>
>VIRTUAL BASES
>
>We may allocate any number of empty virtual base subobjects at offset 0,
>and they will share the complete object's vptr.  Non-empty virtual base
>subobjects get allocated at the end of the complete object.

This again assumes that they have no virtual functions of their own.
Why is this even an interesting case?  No data is common, no virtual
functions in a virtual base class is extremely uncommon, since they
are then essentially useless.  There are rare cases when the
class contains only static members, but I haven't seen many of them.

>(Oh, another point.  I don't have a proof, but my guess is that
>finding an optimal space-minimizing solution to the class layout
>problem is equivalent to the travelling salesman problem.  I'm not
>going to try.  What I'm going to present tomorrow is a heuristic
>that I think should usually do better than just declaration order.)

I would need to see real numbers on real programs before I am convinced
that such algorithms are other than bugs waiting to happen.

-Mike-