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 08:35:50

DUPUIS Etienne wrote:
> I second Andrey, whatever the type T is, it would be nice to have an easy 
> way of specifying a stronger alignment constraint. This is particularly 
> useful to allocate for example buffers of uint8_t on 16-byte or 64-byte 
> boundaries for performance reasons.

You're perhaps missing a certain subtlety here and it is that the 
container/algorithm taking the allocator<T> may allocate objects other than 
T. It does this via rebind<>. And the question then becomes, do you want 
this 64 byte boundary to also apply to these additional allocations? The 
answer is often 'no' - you don't want deque<T>'s bookkeeping structures to 
be overaligned - but sometimes it's 'yes', if you passed allocator<float> 
but the function actually uses allocator<char>. And sometimes, as with 
list<T>, the answer is non-binary.

If the required alignment is equal to alignof(T), it all works - structures 
having T as a member will automatically receive an alignment at least as 
strict, and functions using allocator<char> instead of allocator<T> will 
take the necessary steps to std::align the resulting pointer at alignof(T).

So if you allocate T = struct { char[64]; } alignas(64), it would avoid all 
these complications. This depends on the compiler providing a proper support 
for overaligned types. But that's needed for __m128 and __m256, so I'd 
expect it to be there.

Not that aligned_allocator<T, A> would not be useful; it would be, as long 
as it works. There's no guarantee that it will in all cases though.