Re: Several useful utility classes uploaded

From: brianjparker_at_[hidden]
Date: 2001-10-28 07:50:49

--- In boost_at_y..., Douglas Gregor <gregod_at_c...> wrote:
> 
> I won't claim that the version I supplied definitely covers all 
possible 
> cases. I would suggest that we follow the approach described at:
> http://www.oonumerics.org/tmpw01/alexandrescu.pdf

I just had a look at this paper- the procedure he describes is, I 
think, in essence exactly the same as is used in the alignment_traits 
class I submitted (which BTW is based on a class by Valentin 
Bonnard). Given a collection of base types that cover all alignment 
possibilities, he creates a structure including only the base types 
that are smaller than the supplied type. 

(Actually, one could add an additional test- that the base type also 
has the same alignment as the supplied type- which could in theory 
give a less conservative final alignment but could fail if 
alignment_of is not accurate.)
 
> > > Do you agree that boost::alignment_of<T>::align_t would be the 
best
> > > way to integrate it into Boost?
> >
> > Partially.
> > 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<>.

Yes, I too think we should avoid complicated metaprogramming 
implementations to solve this simple problem, both for portability
and to avoid increase compile times. The implementation described in 
alexandrescu.pdf seems to require typelists and other metaprogramming 
machinery. The implementation I submitted is fairly simple but 
requires partial specialisation; perhaps a simpler implementation 
could be devised.

> However, we could perhaps use a pessimistic align_t where 
metaprogramming 
> isn't possible to get around this (foolish) problem.

Agreed, in a worst-case scenario align_t could just be a typedef for 
some worst-alignment type.

,Brian Parker.