Re: [boost] reinterpret_cast : differents structs or classes with identical structural type

From: Marco (mrcekets_at_[hidden])
Date: 2007-10-02 17:30:12

On Tue, 02 Oct 2007 20:21:12 +0200, Sebastian Redl  
<sebastian.redl_at_[hidden]> 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/