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
