@safe containers with std.experimental.allocator

[Andrei Alexandrescu via Digitalmars-d]

On 1/21/17 5:44 PM, bitwise wrote:
> About alignedMalloc:
>
> In C++ for example, I may want to use a vector full some SIMD type:
>
> class alignas(16) Vec4 {
>     union {
>         struct { float x, y, z, w; };
>         __m128 m;
>     };
> };
>
> std::vector<Vec4> points = { ... };
>
> In C++ however, 'new' does not respect over-alignment:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0035r2.html
>
> Even if new respected alignment, there is no gauruntee all containers,
> STL or otherwise, would use 'new' as opposed to malloc by default(maybe
> one day?)
>
> So I use a custom aligned allocator:
>
> template <class T, int ALIGN>
> class AlignedAllocator {
>     T* allocate(size_type n) {
>         return (T*)_aligned_malloc(ALIGN, n * sizeof(T));
>     }
> };
>
> SIMD operations(aligned load and store) can now safely be used on the
> contents of the std::vector<Vec4>.
>
> std::vector knows nothing about the alignment of the memory it uses. It
> only knows to call allocate() of whatever allocator it's given. If I had
> an allocator with a function 'alignedAllocate' it wouldn't do any good.
> I believe this is the _correct_ design, and that a container _shouldn't_
> have to know about where from, or what kind of memory it's getting.

I understand. That's a questionable design. It only works by virtue of a 
long-distance convention between the rigged allocator and the element 
type of the vector.

> Considering the above use case, alignedAllocate() is redundant, and
> possibly confusing.

Well, you just made use of it in the rigged allocator.

> About missing alignedDeallocate:
>
> while aligned_alloc(), which works in combination with regular 'free()',
> is supposed to be standard as of C++11, it's still not supported in
> visual studio 2015. Instead, one must use _aligned_malloc, and
> _aligned_free. Passing memory from _aligned_malloc to the regular
> version of free() causes a crash. Thus, different deallocation methods
> are needed for both. Also, there's homegrown aligned_allocate functions
> like the following, which require special deallocation functions because
> of the exta metadata prepended to the memory:
> https://github.com/dlang/phobos/blob/366f6e4e66abe96bca9fd69d03042e08f787d040/std/experimental/allocator/mallocator.d#L134-L134
>
>
> I suppose you could use aligned allocation for _all_ allocations, even
> allocations with default alignment, but that would add extra metadata(at
> least 8 bytes) to _all_ allocations even when its unnecessary.
>
> So a solution could be to include the alignment as a template parameter
> of Mallocator, or provide an second AlignedMallocator(uint). The
> allocate() function of either option would return aligned memory if the
> 'alignment' template parameter was non-default. Then, the idea of memory
> alignment would be abstracted away from the containers themselves.
>
> struct Mallocator(uint alignment = platformAlignment){}){}
> or
> struct AlignedMallocator(uint alignment = platformAlignment){}){}

It seems a matter of time until aligned_alloc gets implemented on Windows.


Andrei