Empty base optimization and operators.hpp

From: Dave Abrahams (abrahams_at_[hidden])
Date: 2000-04-28 22:27:04

FYI, one vendor has responded so far.
I speculated that implementing the empty base optimization for multiple base
classes might break binary compatibility, and that might pose a serious
problem for adopting it as a future enhancement. Seems I was right.

-Dave
----------
From: Matt Austern <austern_at_[hidden]>

Dave,

You're right that the empty base optimization should take care of
this.

At this point I believe that all compiler vendors understand the value
of the empty base optimization.  The only reason it isn't implemented
univerally is that, as you observe, it would badly break binary
compatibility.  There's very little freedom to make this sort of
change.

One of the few times when you have the freedom to do this sort of
thing is when you're targeting a new architecture, which, as it
happens, a lot of vendors are.  You might want to look at the class
layout rules, section 2.4 of the draft multivendor IA-64 C++ ABI,
http://reality.sgi.com/dehnert_engr/cxx/abi.html.  We've given a lot
of thought to doing the empty base optimization as aggressively as
possible.

We believe that an arbitrary number of empty base classes can be
allocated at the same offset, *provided* that none of them have a
common ancestor.  So, for example, if we have this hierarchy
    struct A  { };
    struct B1 { };
    struct B2 : public A { };
    struct B3 : public A { };
    struct B4 { }
    struct D : public B1, public B2, public B3, public B4 { };
then I would expect that a clever compiler would lay out D such
that sizeof(D) is 2.  We can allocate B1 and B2 at offset 0.
B3 can't be at offset 0, but it has byte alignment, so we assign
it to offset 1.  Finally, B3 and B4 can share the same offset.

                        --Matt