Sebastian Redl wrote:
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.
Why make POD-types a special case? I like being able to depend on the order of private members. It allows me to nicely encapsulate my data while using SIMD operations internally. I think that if the compiler figures out that my members would be better off in a different order I'd like it to warn me so I can reorder them myself. I can imagine a cache performance degradation because it reorders my members to make the class size smaller but must access memory randomly in order to initialize them in the constructor in the order they appeared in the class definition instead of accessing them with ascending addresses if they were laid out the order in which they were specified. - Michael Marcin