@safe containers with std.experimental.allocator

[Chris Wright via Digitalmars-d]

On Sat, 21 Jan 2017 05:52:49 +0000, bitwise wrote:

> On Saturday, 21 January 2017 at 05:06:07 UTC, Eugene Wissner wrote:
>> Alligned allocator isn't present in the std.experimental.allocator
>> because IAllocator has a method alignedAllocate()
> 
> 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.

Check the code. CAllocatorImpl's implementation of alignedAllocate 
returns null if the implementation doesn't support alignedAllocate. 
(CAllocatorImpl is the provided implementation of IAllocator.)

> 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.

If you need aligned memory, you need to use alignedAllocate. You could 
unconditionally wrap the given allocator using BitmappedBlock, but this 
adds unnecessary overhead if the user passed in an allocator that 
supports aligned allocation.