"no base classes of the same type as the first non-static data member"

Question

I asked this a while ago on comp.std.c++ and got no reply.

I'm just going to quote my post there with little modification.

---

Is the last requirement of standard-layout classes, 9/6, necessary or useful?

A footnote explanation is provided:

This ensures that two subobjects that have the same class type and that belong to the same most-derived object are not allocated at the same address (5.10).

Taken alone, the footnote is incorrect. Two empty base classes with a common base class may produce two instances of the base class at the same address.

struct A {};
struct B : A {};
struct C : A {};
struct D : B, C {};

D d;
static_cast<A*>(static_cast<B*>(&d))
   == static_cast<A*>(static_cast<C*>(&d)); // allowed per 1.8/5

Taken in the context of 5.10, subobjects are only mentioned in the comparison requirements of pointers to members. Base subobjects are irrelevant. Moreover, it doesn't make sense to give special status to comparison between a (scalar) pointer to a member subobject and a pointer to a base subobject above that of comparison between pointers to base subobjects.

There wasn't such a restriction in C++03. Even if there is an ABI out there that requires every member to be allocated at a different address from any base of the same type, yet already allows the empty base class optimization on the above code, I think the ABI is buggy and the standard shouldn't capture this.

The language goes back to N2172 which suggests that multiple inheritance might cause trouble and need to be disallowed in standard-layout classes to ensure ABI compatibility; however, that was ultimately allowed and in that light the requirement doesn't make sense.

---

For reference, 1.8/5-6:

5 Unless it is a bit-field (9.6), a most derived object shall have a non-zero size and shall occupy one or more bytes of storage. Base class subobjects may have zero size. An object of trivially copyable or standard-layout type (3.9) shall occupy contiguous bytes of storage.

6 Unless an object is a bit-field or a base class subobject of zero size, the address of that object is the address of the first byte it occupies. Two distinct objects that are neither bit-fields nor base class subobjects of zero size shall have distinct addresses.

(footnote) Under the “as-if” rule an implementation is allowed to store two objects at the same machine address or not store an object at all if the program cannot observe the difference.

Additional notes:

10.1/8 refers to the same mystery content at 5.10, but it's also just an informative note.

[Note: … A base class subobject may be of zero size (Clause 9); however, two subobjects that have the same class type and that belong to the same most derived object must not be allocated at the same address (5.10). — end note ]

GCC appears to guarantee that empty base subobjects of the same type are given unique addresses. Example program and output. This seems sufficient to guarantee that objects of a given type are uniquely identified by address. That would be above and beyond the guarantees of the C++ object model, §1.8. Of course this is a good idea, but it doesn't seem required by the Standard. Likewise, the platform ABI can extend this guarantee to a class with the first member aliasing an empty base. The language sets minimum requirements for ABIs; an ABI can add a language feature, and other ABIs can follow suit, and the process of catch-up by the Standard is simply error-prone.

My question is whether the given requirement accomplishes anything in the context of the Standard, not whether it is useful to the user in concert with other ABI guarantees. Evidence that such a unique-address guarantee was intended, and only omitted by accident, would also make the requirement more meaningful.

---

To summarize the answer (or my conclusion, anyway):

The requirement does not theoretically ensure anything, as it's possible anyway to ensure that all objects of a given type have different addresses. When the address of an empty base class subobject conflicts with another object (either another base or a member), the compiler may simply assign it an arbitrary location within the structure. As the standard-layout rules only describe the locations of data members (possibly inherited), the locations of empty bases are still unspecified and perhaps incompatible between similar standard-layout classes. (The locations of non-empty bases are still unspecified as far as I've noticed, and then it's not clear what is meant by "first member" in that case, but they must be consistent in any case.)

In practice, the requirement allows implementations to continue using existing ABIs so long as they include the empty base class optimization. Existing compilers may disable the EBO when the requirement is violated, to avoid the address of the base coinciding with the address of the first member. If the Standard didn't restrict programs this way, libraries and programs would have to be recompiled with updated C++0x compilers… not worth it!

Answer 1

Two empty base classes with a common base class must produce two instances of the base class at the same address.

I don't think so. In fact a quick check with my copy of g++ indicates that I have two distinct A object addresses. I.e. your code above is not true.

The fact is, we must have two A objects by the way your classes are written. If two objects share the same address they are not two different objects in any meaningful sense. Thus, it is required that distinct addresses exist for the instances of the A object.

Suppose that A is defined like so:

class A
{
   static std::set<A*> instances;
   A() { instances.insert(this); }
   ~A() { instances.remove(this); }
}

If both copies of A are allowed to share an address this code will not function as it was intended. I believe that it is situations like these where the decision is made that we ought to have distinct addresess for different copies of A. Of course, it's the wierdness of situations like this that make me avoid multiple inheritance.