From: David Abrahams (dave_at_[hidden])
Date: 2005-10-28 11:58:15
Martin Bonner <martin.bonner_at_[hidden]> writes:
> ----Original Message----
> From: David Abrahams [mailto:dave_at_[hidden]]
> Sent: 27 October 2005 12:57
> To: boost_at_[hidden]
> Subject: Re: [boost] alignment trouble with boost::optional
>> Michael Shepanski <mshepanski_at_[hidden]> writes:
>>> On 10/26/05, David Abrahams <dave_at_[hidden]> wrote:
>>>> I think the problem is that type_with_alignment can't find a type
>>>> that has an alignment of 12. Producing an error in that case is the
>>>> right behavior. We could add the type whose alignment_of<> is 12 to
>>>> the reperotoire of types being tested by type_with_alignment...
>>> Don't we need to be sure that type_with_alignment<> can accept *any*
>>> number that alignment_of<> produces -- or, conversely, make sure that
>>> alignment_of<> only produces numbers that type_with_alignment<> can
>>> accept? (I'm assuming that we want boost::optional to work all the
>>> time, not just for my example.)
>> Sure, that's what we want. Can you figure out *how*? That's the
> In summary:
> 1. alignment_of<T> produces a number that is a multiple of the required
> 2. type_with_alignment<> cannot deal with all the numbers that
> alignment_of<> produces.
> Does anyone know of any platform (including platforms that are no longer in
> use), where the alignment requirement was /not/ a power of two? If not,
> then alignment_of<> "just" needs to eliminate the factors from its result
> which are not a power of two. (That would also allow us to eliminate the
> special case for long double under Borland).
That's an interesting heuristic. It trades away some theoretical
safety for some practical utility. Should we try to warn in these
cases, with a PP symbol that you can define to silence the warnings?
Can we add some config macro that tells us when it is truly safe? Is
there a config test we can run that will tell us at runtime?
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk