@safe containers with std.experimental.allocator

Andrei Alexandrescu via Digitalmars-d digitalmars-d at puremagic.com
Sat Jan 21 08:28:16 PST 2017


On 01/21/2017 01:06 AM, Eugene Wissner wrote:
> On Saturday, 21 January 2017 at 05:52:49 UTC, bitwise wrote:
>> I hadn't noticed this, but I immediately see two problems:
>>
>> 1) there is no alignedDeallocate() which is needed because aligned
>> allocators usually prepend metadata containing a pointer to the actual
>> start of the memory to be passed to free(). So deallocate() can't know
>> if the memory came from allocate() or alignedAllocate(), and hence
>> does not now how to properly free the memory.
>>
>> 2) The whole point of using an allocator is that is allocates memory
>> in a different way, but provides a standard interface. It shouldn't be
>> up to a container to know whether to call allocate() or
>> alignedAllocate(). A container should simply call allocate() of
>> whatever allocator it was given.
>
> yes, agreed. alignedAllocate() seems then to make the interface
> complexer without reason.

alignedAllocate provides access to OS/clib-provided primitives for 
aligned allocation. Those don't require a special deallocation function, 
see e.g. http://en.cppreference.com/w/c/memory/aligned_alloc. -- Andrei


More information about the Digitalmars-d mailing list