On Monday, 22 December 2014 at 16:51:30 UTC, Allocator stack
wrote:
How about allocators stack? Allocator e.g. one of these
https://github.com/andralex/phobos/blob/allocator/std/allocator.d
-------------
allocatorStack.push(new GCAllocator);
//Some code that use memory allocation
auto a = ['x', 'y'];
a ~= ['a', 'b']; // use allocatorStack.top.realloc(...);
allocatorStack.pop();
-------------
Allocators must be equipped with dynamic polymorphism. For those
cases when it is too expensive attribute
@allocator(yourAllocator) applied to declaration set allocator
statically.
-------------
@allocator(Mallocator.instance)
void f()
{
// Implicitly use global(tls?) allocator Mallocator when
allocate an
object or resize an array or etc.
}
@allocator("StackAllocator")
void f()
{
// Implicitly use allocatorStack.top() allocator when allocate
an
object or resize an array or etc.
}
-------------
There is some issues to solve. E.g. how to eliminate mix memory
from different allocators.
There are only a couple of constructs in D that allocate, so it
may be worthwhile to let the allocator control the primitives,
i.e.:
auto gc = new GCAllocator(...);
gc.Array!char a = ['x', 'y'];
a ~= ['a', 'b']; //use allocatorStack.top.realloc(...);
//I don't remember the proposed API for
//allocators, but you get the idea
gcAlloc.DestroyAll();
This looks a bit uglier, but it also doesn't require any new
language constructs. The downside is, how do you manage things
like closures doing it this way?
