C and C ++ ensure that the fields are laid out in memory in the same order as you define them. For C ++, which is only guaranteed for type POD 1 (anything that would be legal as C struct [Edit: C89 / 90 - not, for example, C99 VLA] would also qualify as POD).
The compiler can insert additions between members and / or at the end of the structure. Most compilers give you some way of managing this (e.g. #pragma pack(N) ), but it depends on the compilers.
1 Well, there is one corner case that they did not think about, where it is not guaranteed for the POD type - the access specifier violates the order guarantee:
struct x { int x; int y; public: int z; };
This is a POD type, but public: between y and z means that they can theoretically be reordered. I am sure that this is purely theoretical - I do not know of any compiler that changes the order of members in this situation (and if the memory does not succeed today even worse than usual, 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 a cumulative class that does not have non-volatile data members such as a pointer to a member, a non-POD-struct, POD-union (or an array of such types) or a link, and does not have a user-defined copy assignment operator and non-user-defined destructor.
and §8.5.1 / 1:
An aggregate is an array or class (section 9) declared constructors (12.1), no private or protected non-static data elements (section 11), without base classes (section 10) and there are no virtual functions (10.3).
and §9.2 / 12:
... the distribution order of non-static data elements separated by an access specifier is not specified (11.1).
Although this was somewhat limited to paragraph 9.2 / 17:
A pointer to a POD structure object properly transformed using reinterpret_cast points to its initial member ...
Therefore (even if it is preceded by a public: first member you define must be the first in memory. Other members separated by public: qualifiers can theoretically be reordered.
I should also point out that there is room for debate about this. In particular, there is also a rule in 9.2 / 14:
Two types of POD-struct (section 9) are compatible with layouts if they have the same number of non-static data elements, and the corresponding non-static data members (in order) have types compatible with layouts (3.9).
Therefore, if you have something like:
struct A { int x; public: int y; public: int z; };
The format is required to be compatible with:
struct B { int x; int y; int z; };
I am sure that this / was intended to mean that the members of the two structures should be located equally in memory. Since the second, obviously, cannot regroup its members, the first should not be either. Unfortunately, the standard never defines what “layout compatibility” means, which makes the argument weak at best.