Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at