Why is C++11's POD "standard layout" definition the way it is?

Question

I'm looking into the new, relaxed POD definition in C++11 (section 9.7)

A standard-layout class is a class that:

• has no non-static data members of type non-standard-layout class (or array of such types) or reference,
• has no virtual functions (10.3) and no virtual base classes (10.1),
• has the same access control (Clause 11) for all non-static data members,
• has no non-standard-layout base classes,
• either has no non-static data members in the most derived class and at most one base class with non-static data members, or has no base classes with non-static data members, and
• has no base classes of the same type as the first non-static data member.

I've highlighted the bits that surprised me.

What would go wrong if we tolerated data members with varying access controls?

What would go wrong if the first data member was also a base class? i.e.

struct Foo {};
struct Good : Foo {int x; Foo y;};
struct Bad  : Foo {Foo y; int x;};

I admit it's a weird construction, but why should Bad be prohibited but not Good?

Finally, what would go wrong if more than one constituent class had data members?

Answer 1

It's basically about compatibility with C++03 and C:

• same access control - C++03 implementations are allowed to use access control specifiers as an opportunity to re-order the (groups of) members of a class, for example in order to pack it better.
• more than one class in the hierarchy with non-static data members - C++03 doesn't say where base classes are located, or whether padding is elided in base class subobjects that would be present in a complete object of the same type.
• base class and first member of the same type - because of the second rule, if the base class type is used for a data member, then it must be an empty class. Many compilers do implement the empty base class optimization, so what Andreas says about the sub-objects having the same address would be true. I'm not sure though what it is about standard-layout classes that means it's bad for the base class subobject to have the same address as a first data member of the same type, but it doesn't matter when the base class subobject has the same address as a first data member of a different type. [Edit: it's because different objects of the same type have different addresses, even if they're empty sub-objects. Thanks to Johannes]

C++0x probably could have defined that those things are standard-layout types too, in which case it would also define how they're laid out, to the same extent it does for standard-layout types. Johannes's answer goes into this further, look at his example of a nice property of standard-layout classes that these things interfere with.

But if it did that, then some implementations would be forced to change how they lay out the classes to match the new requirements, which is a nuisance for struct compatibility between different versions of that compiler pre- and post- C++0x. It breaks the C++ ABI, basically.

My understanding of how standard layout was defined is that they looked at what POD requirements could be relaxed without breaking existing implementations. So I assume without checking, that the above are examples where some existing C++03 implementation does use the non-POD nature of the class to do something that's incompatible with standard layout.