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

From: David Abrahams (dave_at_[hidden])
Date: 2005-11-10 11:47:45

Michael Shepanski <mshepanski_at_[hidden]> writes:

> Hello again. I'd like to reawaken this thread because It didn't seem to
> reach a conclusion, and the bug that started it continues to cause me pain.
>
>
> On 10/29/05, Fernando Cacciola <fernando_cacciola_at_[hidden]> wrote:
>>
>>
>> As Martin Bonner suggested, one solution is to factorize the result of
>> alignment_of<> so it returns not just any multiple. Unfortunately, we
>> can't
>> say that the alignment _ought_ to be a power of 2 can we?
>>
>> An alternative solution that, at least, would work with this very specific
>> example, is to compute it as the minimun of sizeof(charT)-sizeof(T) and
>> sizeof(Tchar)-sizeof(T)
>> That is, adding the char both before and after, and taking the least
>> difference.
>
>
>
> These both sound like interesting solutions; what do others think?
> Are they theoretically correct?

The second one certainly won't work.  It's very possible that
sizeof(Tchar) - sizeof(T) is zero, while T may still have alignment
requirements.

The first one isn't theoretically correct, because an arbitrary
machine might have non-power-of-2 alignments.  However, it's very
likely to work for on any machine we target in the forseeable future.

> A policy question: what happens if no theoretically correct solution
> is found? Would boost::optional then be discontinued? 

Of course not.

> Or would it be reimplemented in a way that happens to work on all
> popular platforms? 

That's what we do now.  Except that someone found a case where it
fails.

> Or would it switch at compile-time between
> overtly platform-specific implementations?

How to address it is up to the maintainer.

> I do hope that the policy is not to keep the current solution until a
> theoretically correct solution is comes to light. 

I doubt it, because there is no such solution.

> Not to put too fine a point on it, the current solution is
> theoretically incorrect too; the only thing that distinguishes it
> from other theoretically incorrect solutions that have been
> discussed is that this one fails in practice.

That's one way to look at it.  The other way is to say that it refuses
to silently return a wrong answer, preferring instead to cause a
compile-time error so we will notice the problem and have this
discussion about addressing it.  I think that even if we take the
biggest factor of 2 that evenly divides the detected alignment, it's
still possible to come out with a number so large that none of the
fundamental types we use to force alignment will handle it.  I hope in
that case we'll continue to produce a compile-time error.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com