Long term @nogc / allocators usage
Seb via Digitalmars-d
digitalmars-d at puremagic.com
Sun Jul 24 10:04:43 PDT 2016
On Sunday, 24 July 2016 at 15:34:55 UTC, Lodovico Giaretta wrote:
> DISCLAIMER: although I've been occasionally using D for a lot
> of time, I only recently started to follow the forums and use
> it intensively, so I may miss part of the history / long term
> vision.
>
> So, the current guidelines to make a function usable in @nogc
> are:
> 1) use ranges as much as possible, instead of arrays;
> 2) don't specify a precise delegate type, but make it templated
> (so you accept both gc and @nogc delegates);
> 3) use manual management (e.g. malloc/free) for internal
> buffers whose lifetime and ownership are easy to track.
>
> Now, there are some cases in which you cannot avoid the managed
> allocations:
> 1) throwing exceptions: these should not be abandoned in favor
> of other solutions; IMHO, they should be easily usable in @nogc
> code; switching to error codes or user-defined callbacks is not
> feasible in general;
> 2) returning arrays: sometimes you just can't avoid this: if
> your function must return a string, than it has to allocate it
> (unless it's a slice of some input)
>
> With the new allocators library, we can customize these
> allocations. There are two possible ways to follow, both with
> advantages and drawbacks:
> 1) have all allocating functions take a templated allocator
> parameter (defaulting to GCAllocator) and use it to allocate
> returned arrays and thrown exceptions; this allows the compiler
> to infer @nogc whenever a @nogc allocator is passed, but
> becomes bloated because you have to carry around another
> parameter to lots of functions
When I had to deal with this problem, I liked this idea too, but
1) Allocations with GCAllocator (e.g. makeArray) are neither
@safe, nothrow nor pure.
2) It creates a huge template bloat
For 1) the best solution is WIP here:
https://github.com/dlang/phobos/pull/3891
> 2) have all allocating functions use theAllocator instead of
> raw new to perform allocations. This would make the allocator
> parameter implicit and the code very easy (just set
> theAllocator on startup), but would not allow the compiler to
> infer @nogc; IMHO it's not that bad: you can always use the
> profiler to check that your code is in fact @nogc, even if not
> stated explicitly; but many will not agree with this.
Yep it destroys the point of @nogc, besides different data
structures / algorithms profit from different, specialized
allocators.
> So my question is: what's the plan? Which road is to be
> followed? How will Phobos evolve regarding this?
There are also other options [1], e.g.
- using `static if`
- using two separate functions (one with `new`)
- requiring the API user to allocate the data beforehand
[1] https://github.com/dlang/phobos/pull/4190
More information about the Digitalmars-d
mailing list