• maik klein (11/11) Nov 14 2015 http://dlang.org/phobos/std_experimental_allocator.html
• Xinok (9/20) Nov 14 2015 Allocators provide mechanisms for allocating memory but don't do

maik klein <maikklein googlemail.com> writes:

http://dlang.org/phobos/std_experimental_allocator.html

I am not sure what the plan is but it seems to me that the 
standard library could make use of the "theAllocator" for 
allocation and also allow you to swap in different allocators.

So could it then be possible to completely bypass the GC once 
"allocators" are used by the std?

I imagine that we could set "theAllocator = Malloc" and every 
allocation will use malloc? Or maybe some function allocates by 
default but you know that the allocation is small enough to be 
allocated on the stack which would allow us to call the function 
like this "someFunction!(StackAlloactor)(foo);" ?

Xinok <xinok live.com> writes:

On Saturday, 14 November 2015 at 14:56:57 UTC, maik klein wrote:
 http://dlang.org/phobos/std_experimental_allocator.html

 I am not sure what the plan is but it seems to me that the 
 standard library could make use of the "theAllocator" for 
 allocation and also allow you to swap in different allocators.

 So could it then be possible to completely bypass the GC once 
 "allocators" are used by the std?

 I imagine that we could set "theAllocator = Malloc" and every 
 allocation will use malloc? Or maybe some function allocates by 
 default but you know that the allocation is small enough to be 
 allocated on the stack which would allow us to call the 
 function like this "someFunction!(StackAlloactor)(foo);" ?

Allocators provide mechanisms for allocating memory but don't do 
anything for memory management. Unlike the GC which automatically 
frees memory, you must explicitly free memory in allocators. In 
fact, some allocators aren't even required to implement free().

Allocators and containers should go a long way in eliminating 
much use of the GC in the std library. However, some language 
features still rely on the GC and we'll need alternate mechanisms 
to deal with those, such as RC or lifetime semantics (a la Rust).