EBCO and inheritance

[Dave]

class not_empty
{
int a,b;
};

class empty {};

class derived: public not_empty, empty
{
double c, d;
};

derived d;

empty *ptr = &d;

Does the assignment above prevent EBCO from being applied? If not, where
does ptr point?

 

[Rob Williscroft]

Dave wrote in in comp.lang.c++:

class not_empty
{
int a,b;
};

class empty {};

class derived: public not_empty, empty
{
double c, d;
};

derived d;

empty *ptr = &d;

Does the assignment above prevent EBCO from being applied? If not, where
does ptr point?

No, it points at d or somewhere within d.

Why do you think it matters ?

Rob.

 

[Dave]

Dave wrote in in comp.lang.c++:


No, it points at d or somewhere within d.

Why do you think it matters ?

Rob.

It's just a theoretical question. I don't doubt that the modern
implementations of good reputation got it right or that it materially
affects me. I just had the impression that a base class pointer had to
point to a subobject of its static type, but I don't see how that could be
possible in this case if the compiler applies EBCO.

 

[Rob Williscroft]

Dave wrote in in comp.lang.c++:

It's just a theoretical question. I don't doubt that the modern
implementations of good reputation got it right or that it materially
affects me. I just had the impression that a base class pointer had
to point to a subobject of its static type, but I don't see how that
could be possible in this case if the compiler applies EBCO.

Giving each object a unique address, is why empty classes are given
the extra byte in the first place. But when the class is used as
a base class all that is needed is that each base class and subobject
have a unique address pre type property. I.e. its ok for subobjects
to share the same address as long as they dont share the same type:

struct A { int a; };
strudt B : A {};

B b;
A &a = b;

In the above a referes to b and has the same address, but the type's
are different.

EBO/EBCO:

struct empty {};
struct derived : empty {};

No (visible) EBO:

struct derived2 : empty { empty e; };

In the above the base class empty *can't* share the same address
with derived2::e, so derived2 *must* be at least 2 bytes in
size.

struct derived3 : empty, empty {};

Here only 1 of the base classes *could* be EBO'd but then
a padding byte would be needed so that the second got a unique
address, so 2 bytes minimum again,

struct data { char b; };

EBO (again):

struct derived4 : empty, data, empty {};

here 1 of the empty base classes can have EBO, applied
as the 2nd can have a unique address inspite of this.

As you can imagine, once you start considering multiple
"inheritance" of base classes with base classes, things
start to get real hairy. Fortunatly the mess has to be
sorted out by a comupter programme , not us.


Rob.