Boost logo

Boost :

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

> 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

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