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

From: Michael Shepanski (mshepanski_at_[hidden])
Date: 2005-10-27 23:35:55

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.

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.

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.

4. Maybe it's possible to write code that selects option 3 only
for non-PODs, and otherwise either uses offsetof (i.e. option 1)
or does what it does now. Downside: there's still the downside
of 3, when it's selected. Also I'm not sure whether it's possible
to do the template metaprogramming to choose one
implementation for PODs and another for non-PODs.

--- Michael Shepanski