Boost logo

Boost :

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

* 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.

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