Do class/struct members always get created in memory in the order they were declared?

Question

This is a question that was sparked by Rob Walker's answer here.

Suppose I declare a class/struct like so:

struct
{ 
    char A;
    int B;
    char C;
    int D;
};

Is it safe to assume that these members will be declared in exactly that order in memory, or is this a compiler dependent thing? I'm asking because I had always assumed that the compiler can do whatever it wants with them.

This leads into my next question. If the above example causes memory alignment issues, why can the compiler not just turn that into something like this implicitly:

struct
{ 
    char A;
    char C;
    int B;
    int D;
};

(I'm primarily asking about C++, but I'd be interested to hear the C answer as well)

Related topics

• Why doesn't GCC optimize structs?

Answer 1

I cannot speak for C++, but in C the order is guaranteed to be the same order in memory as declared in the struct.

Answer 2

The data members are arranged in the order declared. The compiler is free to intersperse padding to arrange the memory alignment it likes (and you'll find that many compilers have a boatload a alignment specification options---useful if mixing bits compiled by different programs.).

See also http://stackoverflow.com/questions/118068/why-doesnt-gcc-optimize-structs.

---

It appears that this answer is somewhat obsolete for C++. You learn something everyday. Thanks aib, Nemanja.

Answer 3

Basically, you can count on that only for the classes with a standard layout. Strictly speaking, standard layout is a C++0x thing, but it is really just standardizing existing practice/

Answer 4

C99 §6.7.2.1 clause 13 states:

Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared.

and goes on to say a bit more about padding and addresses. The C89 equivalent section is §6.5.2.1.

C++ is a bit more complicated. In the 1998 and 2003 standards, there is §9.2 clause 12:

Nonstatic data members of a (non-union) class declared without an intervening access-specifier are allocated so that later members have higher addresses within a class object. The order of allocation of nonstatic data members separated by an access-specifier is unspecified (11.1). 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 (10.3) and virtual base classes (10.1).

Answer 5

Aside from padding for alignment, no structure optimization is allowed by any compiler (that I am aware of) for C or C++. I can't speak for C++ classes, as they may be another beast entirely.

Consider your program is interfacing with system/library code on Windows but you want to use GCC. You would have to verify that GCC used an identical layout-optimization algorithm so all your structures would be packed correctly before sending them to the MS-compiled code.

Answer 6

While browsing the related topics at the right, I looked at this question. I figure this may be an interesting corner case when thinking about these issues (unless it's more common than I realize).

To paraphrase, if you have a struct in C that looks something like this:

struct foo{};

and subclass it like so in C++ (using a separate compilation unit):

extern "C" foo;
struct bar: public foo{};

Then the memory alignment won't necessarily be the same for the reasons aib mentions (even amongst compilers from the same vendor).