why allocators are not discussed here
cybervadim
vadim.goryunov at gmail.com
Wed Jun 26 07:31:40 PDT 2013
On Wednesday, 26 June 2013 at 14:26:03 UTC, H. S. Teoh wrote:
> Yeah, I think the best approach would be one that doesn't
> require
> changing a whole mass of code to support. Also, one that
> doesn't require
> language changes would be far more likely to be accepted, as
> the core D
> devs are leery of adding yet more complications to the language.
>
> That's why I proposed that gc_alloc and gc_free be made into
> thread-global function pointers, that can be swapped with a
> custom
> allocator's version. This doesn't have to be visible to user
> code; it
> can just be an implementation detail in std.allocator, for
> example. It
> allows us to implement custom allocators across a block of code
> that
> doesn't know (and doesn't need to know) what allocator will be
> used.
>
Yes, being able to change gc_alloc, gc_free would do the work. If
runtime remembers the stack of gc_alloc/gc_free functions like
pushd, popd, that would simplify its usage.
I think this is a very nice and simple solution to the problem.
More information about the Digitalmars-d
mailing list