Michael Shepanski <mshepanski@gmail.com> 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@hotmail.com> 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