Question

Is the way C++ structs are laid out set by the standard, or at least common across compilers?

I have a struct where one of its members needs to be aligned on 16 byte boundaries, and this would be easier if I can guarantee the ordering of the fields.

Also, for non-virtual classes, is the address of the first element also likely to be the address of the struct?

I’m most interested in GCC and MSVS.

Answer 1

C and C++ both guarantee that fields will be laid out in memory in the same order as you define them. For C++ that’s only guaranteed for a POD type¹ (anything that would be legitimate as a C struct [Edit: C89/90 — not, for example, a C99 VLA] will also qualify as a POD).

The compiler is free to insert padding between members and/or at the end of the struct. Most compilers give you some way to control that (e.g., #pragma pack(N)), but it does vary between compilers.

¹Well, there is one corner case they didn’t think of, where it isn’t guaranteed for a POD type — an access specifier breaks the ordering guarantee:

struct x { 
    int x;
    int y;
public:
    int z;
};

This is a POD type, but the public: between y and z means they could theoretically be re-ordered. I’m pretty sure this is purely theoretical though — I don’t know of any compiler that does reorder the members in this situation (and unless memory fails me even worse than usual today, this is fixed in C++0x).

Edit: the relevant parts of the standard (at least most of them) are §9/4:

A POD-struct is an aggregate class that has no non-volatile
data members of type pointer to member, non-POD-struct, non-
POD-union (or array of such types) or reference, and has no
user-defined copy assignment operator and no user-defined
destructor.

and §8.5.1/1:

An aggregate is an array or a class (clause 9) with no user-
declared constructors (12.1), no private or protected non-
static data members (clause 11), no base classes (clause 10)
and no virtual functions (10.3).

and §9.2/12:

…the order of allocation of non-static data members
separated by an access-specifier is unspecified (11.1).

Though that’s restricted somewhat by §9.2/17:

A pointer to a POD-struct object, suitably converted using
a reinterpret_cast, points to its initial member…

Therefore, (even if preceded by a public:, the first member you define must come first in memory. Other members separated by public: specifiers could theoretically be rearranged.

I should also point out that there’s some room for argument about this. In particular, there’s also a rule in §9.2/14:

Two POD-struct (clause 9) types are layout-compatible if they have the same number of nonstatic data members, and corresponding nonstatic data members (in order) have layout-compatible types (3.9).

Therefore, if you have something like:

struct A { 
    int x;
public:
    int y;
public:
    int z;
};

It is required to be layout compatible with:

struct B {
    int x;
    int y;
    int z;
};

I’m pretty sure this is/was intended to mean that the members of the two structs must be laid out the same way in memory. Since the second one clearly can’t have its members rearranged, the first one shouldn’t be either. Unfortunately, the standard never really defines what “layout compatible” means, rendering the argument rather weak at best.