Re: [boost] [optional] memory use for optional refs and ptrs

Subject: Re: [boost] [optional] memory use for optional refs and ptrs
From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2010-10-06 09:28:50

On 06.10.2010 14:26, Stewart, Robert wrote:
> Sebastian Redl wrote:
>    
>> On 06.10.2010 14:09, Rutger ter Borg wrote:
>>      
>>> On 2010-10-06 13:11, Stewart, Robert wrote:
>>>
>>>        
>>>> (I haven't looked, but I do hope that the bool follows the
>>>> optional value to reduce padding overhead.)
>>>>          
>>> It doesn't, the boolean is followed by the optional value (see
>>> boost/optional/optional.hpp lines 447-448).
>>>        
>> I really don't think it makes a difference. Unless you're using
>> compiler-specific packing instructions, the size of a struct
>> will always be a multiple of the largest alignment of any of its
>> subobjects. In other words, no matter where you place the bool,
>> it will take as much space as the alignment of the value.
>>      
> When the bool follows the value, it can occupy otherwise unused padding between data members.
>    
I really don't think so. Maybe in theory, but not in practice, for 
various reasons. One is that an ABI that allows this would be very 
complicated to specify. Another is that optional uses something like 
aligned_storage, which hides padding of the type is is a placeholder 
for. And even the theory is only a maybe - depending on exact wording of 
the address ordering rules of C++, it might simply be forbidden, or the 
only allowed thing might be to place things in trailing padding of the 
directly preceding element. But as I said, aligned_storage ruins all 
optimization opportunities anyway.
A more interesting question is whether placing the bool at the end would 
mean that since the bool's padding is now trailing, other stuff can be 
placed in there.
I've read and re-read the Common C++ ABI, which is an evil, hard-to-read 
(and sometimes downright misworded) document, and I have come to the 
conclusion that compilers that follow it can't do that. Maybe compilers 
that follow other ABIs.

Sebastian