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.