Allocators stack

[Allocator stack via Digitalmars-d]

On Monday, 22 December 2014 at 21:09:21 UTC, Meta wrote:
>
> 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?

In this case you have to make all things template on allocator or 
even more on Allocator!T making Cartesian product of allocators 
and types. The point is to provide method to handle different 
memory management strategies by user in run time.

It is ease to give up GC using annotation and run time stack. Set 
an allocator for a class by annotation(apply for all methods) and 
it force std library to use the allocator whenever you use it in 
the class.