[basic.types.general] Object and value representation of a non-bit-field subobject seem underspecified

[frederick-vs-ja]

Full name of submitter (unless configured in github; will be published with the issue): Jiang An

Reference (section label): [basic.types.general]

Link to reflector thread (if any):

Issue description:

The resolution of CWG2519 made [basic.types.general] p4 cover non-bit-field complete objects and bit-field objects, but left non-bit-field subobject uncovered. Perhaps we should specify the object and value representations in a way consistent with complete objects.

Moreover, the latter occurrence of "complete" in the following sentence seems questionable because there're some complete types of which complete objects don't exist (i.e. abstract class types).

The object representation of a complete object type T is the sequence of N unsigned char objects taken up by a non-bit-field complete object of type T, where N equals sizeof(T).

Perhaps such oddity should also be addressed by CWG2817.

Suggested resolution:

Modify [basic.types.general] as indicated:

4. [...] The object and value representation of a non-bit-field complete object of type T are the bytes and bits, respectively, of the object corresponding to the object and value representation of its type. [...]

[Eisenwave]

Keep in mind that except for trivially copyable types, compilers may optimize class layouts so that objects live in the padding bits of other objects, etc., In other words, the surrounding complete object is in charge of giving bytes to its subobjects, not each individual subobject, and the wording should reflect that (the proposed resolution doesn't). Maybe it's fine though; it's not like wording for bit-fields emphasizes that fact either.

struct S {
  // S(S&&) {}
  int x;
  char c;
};

struct D : S {
  char d;
};

static_assert(sizeof(D) == 12); // evaluates to 8 == 12 when uncommenting move constructor

[frederick-vs-ja]

Keep in mind that except for trivially copyable types, compilers may optimize class layouts so that objects live in the padding bits of other objects, etc.,

I think this is because of that Itanium ABI does care for the pre-CWG43 specification, which effectively disallowed a base class subobject of a POD type (in ancient C++98 meaning) to be potentially-overlapping.

IMO trivially copyable classes (strictly speaking, classes that are POD for the purpose of layout) shouldn't be exceptions. It's weird for triviality to affect layout (modulo virtual tables), but Itanium ABI decided to do so.

In other words, the surrounding complete object is in charge of giving bytes to its subobjects, not each individual subobject, and the wording should reflect that (the proposed resolution doesn't).

IMO, the crux seems to be that object representations (but not value representations) of two member of base class subobjects can overlap when no one is a subobject of another. The term "potentially-overlapping" seemingly implies that such a case can happen, although the standard wording isn't saying anything about "actually overlapping".