On Tue, 02 Oct 2007 20:21:12 +0200, Sebastian Redl <sebastian.redl@getdesigned.at> wrote:
Marco wrote:
What I'm interesting is if the standard says something about declaration order of struct fields and their storage order in memory. It does. It says that members of a struct or class (even non-POD ones, which I think is a useless restriction) that have no intervening access specifier are stored in memory in the same order as they are declared. 9.2/12 says: 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. 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.
That means:
class foo { int i1; int i2; public: int i3; int i4; public: int i5; };
->
&i1 < &i2 == true &i3 < &i4 == true &i1 < &i3 unspecified &i3 < &i5 unspecified
What surprise me it's that the order of allocation is unspecified even if two adjacent access specifiers are the same. That is &i3 < &i5 unspecified. So access specifiers could be used to hint the compiler that it could reorder member allocation according to its needs.
In particular, although no compiler I know of does it, an implementation can reorder fields to e.g. make the allocation pattern more efficient:
class inefficient { char c1; private: int i1; private: char c2; private: int c2; };
Naively, on a typical 32-bit platform, sizeof(inefficent) would be 16. But with all the intervening access specifiers, a compiler would be allowed to arrange the members as i1,i2,c1,c2 and make sizeof(inefficient) 12.
I see, maybe on some exotic platform this could actually happen, or if the size optimization option is passed to the compiler.
What I personally don't understand is why private members - or in fact all members of non-PODs - can't always be re-ordered. It's not like anyone should ever depend on their order. It probably was C compatibility that there were any guarantees at all.
Sebastian Redl
Thanks for the further explanation. Regards, Marco Cecchetti -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/