From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-10-25 21:25:40
On Thursday 25 October 2001 05:36, you wrote:
> > The best solution, I think, given that the problem cannot be
> > completely solved in current ISO C++, would be a language change that
> > added a standardised alignment_of() and #pragma align that worked on
> > members of structures and in templated code.
> I haven't tought about the core issues involved.
This is actually a relatively common extension. GCC, Microsoft, and EDG-based
compilers support alignof or __alignof__ (same semantics as sizeof).
> > Your alignment_alias<T>::type appears to be a more sophisticated
> > implementation than my alignment_traits<T>::align_t and may do a
> > better job, assuming that boost::alignment_of<>::value is accurate
> > which it is not guaranteed to be.
> The core of alignment_alias<T> was borrowed from Doug's stack based
> variant; so it isn't really *my* implementation.
> > (minor note: I see that your list of base types from which to choose
> > doesn't include a POD- I had the vague impression that some C++
> > implementations can give a structure a different alignment to
> > everything else, so it may be prudent to add one to your list).
> Off the top of my head I think this isn't necessary, but I'll think about
I won't claim that the version I supplied definitely covers all possible
cases. I would suggest that we follow the approach described at:
> > Do you agree that boost::alignment_of<T>::align_t would be the best
> > way to integrate it into Boost?
> If alignment_of<> didn't existed, and we were creating it, yes, I think
> I'll put 'align_t' there.
> But, given that alignment_of<> is already in use, I'm not sure.
> We need to know what other boosters think about this.
I think I like the idea. I only worry about portability because it requires a
bit of metaprogramming to get the align_t type, and that would break under
some compilers that otherwise work with alignment_of<>.
However, we could perhaps use a pessimistic align_t where metaprogramming
isn't possible to get around this (foolish) problem.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk