Where in the C++ Standard is the memory layout of objects documented?

Question

This is a big question, so I'm asking for a reference rather than a booklet-sized answer. I'm going through Stroustrup's Tour of C++, and it seems like the way objects are laid out is memory is fundamental to the design of many C++ features, e.g. PODs vs aggregates vs classes with virtual members.

Unfortunately, the Tour itself doesn't cover this subject in detail, and skimming the ToCs of some standard references such as C++ Primer 5ed and TCPPPL 4ed doesn't show whether or where they cover it.

Larissa

It is ABI specific. See github.com/hjl-tools/x86-psABI/wiki/X86-psABI – Tummy

Some of it is covered by the standard. The rest by the implementation (compiler) – Furst

@BasileStarynkevitch but isn't there some basic assumptions and common aspects? For example, there seem to be some basic assumptions about memory layout behind the reason that aggregates can't contain virtual members. I'm looking to understand these reasons. – Larissa

Not really. The whole purpose of that is to allow implementations to do what they want. – Ardy

Then look into some C++ standard, perhaps open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf – Tummy

Start with en.cppreference.com/w/cpp/language/object and en.cppreference.com/w/cpp/language/types – Tytybald

this is not a 'Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource', it is asking for 'where is the spec for xx', thats 100% on topic – Pacian

I have slightly reworded the headline and voted to reopen. – Lozoya

You may want to add the tag "language-lawyer". – Lawtun

@DunPeal the "aggregate" concept is to do with initialization, not layout – Counterstroke

What the level of details do you need? – Phenomenal

@Phenomenal I just want to know exactly what the standard specifies. – Larissa

@DunPeal About as much as C. – Phenomenal

See also https://mcmap.net/q/334136/-why-is-c-11-39-s-pod-quot-standard-layout-quot-definition-the-way-it-is/963864 – Phenomenal

Answer 1

[class.mem]/18:

Non-static data members of a (non-union) class with the same access control are allocated so that later members have higher addresses within a class object. The order of allocation of non-static data members with different access control is unspecified. Implementation alignment requirements might cause two adjacent members not to be allocated immediately after each other; so might requirements for space for managing virtual functions and virtual base classes.

and [class.mem]/25:

If a standard-layout class object has any non-static data members, its address is the same as the address of its first non-static data member. Otherwise, its address is the same as the address of its first base class subobject (if any). [ Note: There might therefore be unnamed padding within a standard-layout struct object, but not at its beginning, as necessary to achieve appropriate alignment. — end note ] [ Note: The object and its first subobject are pointer-interconvertible ([basic.compound], [expr.static.cast]). — end note ]

There is also [dcl.array] which indicates that arrays are contiguous in memory, [class.bit] which talks about bit-fields, and [intro.object] which talkes about object size and the concept of overlapping subobjects.

There may be other places. There's no one spot.

Seabrooke

That's a good reference, but I am finding statements in other places that claim additional requirements, for instance in cppreference adding details like: "a pointer to an object of standard-layout struct type can be reinterpret_cast to pointer to its first non-static data member (if it has non-static data members) or otherwise its first base class subobject (if it has any), and vice versa. (padding is not allowed before the first data member). Note that strict aliasing rules still apply to the result of such cast". – Larissa

There's also bit fields and arrays. – Yeseniayeshiva

@PasserBy Serves me right for claiming completeness. – Seabrooke

@DunPeal "can be reinterpret_cast" 1) That's a guarantee on an expression, not on layout. The guarantee on layout can exist in theory without the guarantee on expression. 2) Actually, C++ is deeply divided on when a pointer is pointing to an object. One side of C++ says that pointers must be correctly derived, the other side says that any pointer containing the correct address points to any object that happens to live at that address. So there are two C++, one with high level semantic, the other with low level semantic. You need to say which one you are talking about. – Phenomenal