Re: [boost] alignment trouble with boost::optional

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-10-28 11:56:54

Michael Shepanski wrote:
> On 10/27/05, David Abrahams <dave_at_[hidden]> wrote:
>>
>>
>> Sure, that's what we want. Can you figure out *how*? That's the
>> problem.
>
>
>
> I can't think of a perfect solution, but here are some imperfect ones:
>
> 1. Inside type_traits/alignment_of.hpp, the expression:
> sizeof(alignment_of_hack<T>)-sizeof(T)
> is what generates the number 12 in the first place. I think the 12
> comes about because this expression includes the size of padding
> both before and after the t field in alignment_of_hack<T>. If you
> replace this expression with:
> offsetof(alignment_of_hack<T>, t)
> then it seems to work better. The downside is that the standard
> says you can't use offsetof with non-PODs, and gcc gives
> warnings if you try. This may be because offsetof relies on "&"
> --in which case boost::addressof will save the day-- but there may
> be more fundamental reasons to do with unpredictable layout of
> non-PODs.
>
Well, you said it yourself... we can't use this solution becasue it won't 
work for any T.

> 2. We could assume that the alignment of int64_t is good enough
> alignment for anything, and then set up type_with_alignment so
> that it gives you an int64_t by default, i.e. in the cases where it's
> currently failing. Downside: the assumption is probably not
> guaranteed by any C++ standard, so if you meet a platform where
> the assumption fails, then you'll need platform-specific code that
> sets a different default type.
>
Again, as you said, that assumption is not a std requirement so we can't use 
it.

> 3. boost::optional could put the data on the heap (since operator
> new always knows how to get properly aligned memory), and then
> boost::optional could manage it with a smart pointer. Downside:
> it defeats one of the attractions of boost::optional over smart
> pointers, which is that it saves the allocation and indirection
> overhead.
>
Is more than an attraction, it's a fundamental feature. I can't change that.

FWIW, there is sound (IMO at least) alignment proposal for the std, so we 
may not need to worry anymore about this in the not so distant future.

-- 
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com/