Boost logo

Boost :

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

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

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