std.allocator ready for some abuse

[Andrei Alexandrescu]

On 10/24/13 2:44 PM, Vladimir Panteleev wrote:
> On Thursday, 24 October 2013 at 19:53:56 UTC, Andrei Alexandrescu wrote:
>> I know it's been a long wait. Hopefully it was worth it. The alpha
>> release of untyped allocators is ready for tire-kicking and a test drive.
>
> Very, very nice!
>
> One question that immediately jumps out for me:
>
> As a primitive, will deallocateAll always call the parent's
> deallocate/deallocateAll?

That's a gray area for the time being. What I fear (for e.g. HeapBlock) 
is a pathological case in which deallocateAll frees parent's buffer and 
then a reallocation grabs another one etc.

Also I haven't forgotten your suggestion returnsZeroedMemory. I think we 
should implement it at a point.

> Sometimes it's useful to tell a top-level allocator to forget it
> allocated anything, but not actually free memory, so that it can be
> reused - similarly to Appender's clear method. There doesn't seem to be
> an easy way to do it with Freelist, as it will always forward to the
> parent's deallocate or deallocateAll. Perhaps there could be a "clear"
> primitive too?

I think that's a good idea.

> Spied two typos:
> - s/AllocatorWithOptions/AllocatorWithStats/
> - s/an the call/the call/

Fixed, thanks.


Andrei