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