On Thursday, 24 October 2013 at 19:53:56 UTC, Andrei Alexandrescu
wrote:
Hello,
... awesome stuff ...
Please destroy! I've literally sweat as I'm sending this :o).
Andrei
I like it a lot so far.
I was really worried about being able to dynamically dispatch to
an allocator determined at a previous place in the call stack,
and it seems you're all over it with CAllocator. Hell yeah!
I have an editing suggestion for the CAllocator comment:
Instead of
"Implementation of CAllocator using Allocator. [...]"
I suggest
"Implements CAllocator using the given Allocator. [...]"
The current one read strangely to me at first, and I had to
re-read it several times and notice that "Allocator" referred to
the template parameter.
I agree with others that say that the name CAllocator is too
ambiguous or vague. When I scanned through the allocators, I
initially dismissed it because I though it was a proxy for the
system's underlying C allocator, with Mallocator being a D-based
optimized reimplementation of the C allocator. Reading further
clarified this, but it does probably harm skimming and searching.
I suggest an alternative name for CAllocator:
DispatchingAllocator. I believe this may represent what it does:
dispatch allocation to another allocator that is behind a
curtain. Something like AbstractAllocator might work too, but
still seems slightly ambiguous to me (i.e. abstract in what
sense?).
I just hope that the future "top" allocator that handles
language-builtin allocations will be one that can maintain a
stack of allocators and push/pop the current default allocator,
as well as prevent or redirect allocator choice made within calls
to 3rd party libraries (assuming the libraries are written in D,
of course).
