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.