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
> I can't think of a perfect solution, but here are some imperfect ones:
> 1. Inside type_traits/alignment_of.hpp, the expression:
> 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
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
> 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
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/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk