Custom Allocators

[Timon Gehr]

On 04/03/2012 05:47 AM, James Miller wrote:
> I've been doing some reading on dlang.org and the newsgroup archives
> and have seen talk about allocators and things around the garbage
> collector.
>
> I have a few questions about the entire thing:
>
> - I understand that allocators are all about memory management, but
> how does this affect D and the way allocators are integrated into the
> language?

Custom allocators are important for performance optimization. Manual 
memory management is already possible and does not require language changes.

> - How are allocators supposed to work with the GC? I know that you can
> manually allocate memory and add the range to the GC, but why do you
> have to do this?

You can manually allocate memory and not add the range to the GC as long 
as the range does not contain pointers to the GC heap.

> - I've read that custom allocators aren't implemented, but I see
> references to using new() and delete() in classes in the docs? Is this
> one of the cases where the docs are "what it should be" and the
> reality is different? If there aren't custom allocators, then are
> there any major blockers to the addition (or is it just "because
> nobody has added it"?)?

Custom new() and delete() are in the compiler, but Andrei wants them to 
go away. (IIRC he also wanted to deprecate the 'new'-expression some 
time ago.)

Note that custom new() and delete() are not to be used synonymous with 
the notion of custom allocators. They just provide a hook for custom 
allocators.

> - Would it be possible to use custom allocators to write a completely
> GC-free application (using ref-counting instead for example)?

Ref-counting is a form of automated GC.

> Or would the GC still be used anyway?
>

AFAIK you can modify the runtime library so that it does not export the 
GC at all and still get working code.


Also see std.conv.emplace:
http://dlang.org/phobos/std_conv.html#emplace