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
>> 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
>> That is, adding the char both before and after, and taking the least
> 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
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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk