Re: [boost] Review request for Boost.Align

Subject: Re: [boost] Review request for Boost.Align
From: Peter Dimov (lists_at_[hidden])
Date: 2014-02-20 10:07:34

Andrey Semashev wrote:
> I think, current implementations (at least, those I have worked with) 
> don't support this. I.e. if you do std::allocator< __m128 >::allocate(n), 
> you're basically doing new __m128[n], and this does not align memory to 16 
> bytes.

That's not what I had in mind. The use case is aligned_allocator< __m128 >, 
not std::allocator< __m128 >. When you pass such an allocator, the cases 
are:

* A<__m128> is used. We're fine if alignof(__m128) is correct.

* A< something unrelated to __m128 > is used. Fine.

* A< char > is used and the result is aligned to alignof(__m128). Fine, if 
alignof(__m128) is correct.

* A< struct with an __m128 member > is used. Fine if alignof(struct) is at 
least as strict as alignof(__m128) and suitable padding is inserted to align 
the __m128 member.

It is this last requirement - that the implementation should propagate 
extended alignment upwards into structs and align members properly - that I 
said was necessary.

...

> this will likely not work because std::list won't use 
> my_alignment_of<__m128 > but instead some my_alignment_of< list_node< 
> __m128 > >. To make this work you'd have to write some fake metafunction 
> that just always returns 64, and this is equivalent to just specifying 64 
> in aligned_allocator template parameters, only more complicated.

Specifying 64 is not going to work for list<> containers. That was my point.

    template< class T > struct __list_node { void* next_; T t_; }

If you align the __list_node at 64, the t_ member is not going to be aligned 
at 64.

aligned_allocator<T, 64> is going to work for vector<> though, and this is 
often precisely what's needed. So I think that your suggestion of specifying 
a minimal alignment, with the actual alignment being determined as LCM( 
min_align, alignof(T) ) is useful, as long as people realize that it's 
tailored to vector<> and is not generally suitable.