Allocators stack

Meta via Digitalmars-d digitalmars-d at puremagic.com
Mon Dec 22 13:09:20 PST 2014


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?


More information about the Digitalmars-d mailing list