Re: When to call GC.{add,remove}Range in containers?
On Monday, 10 October 2016 at 08:26:45 UTC, Kagamin wrote: On Monday, 10 October 2016 at 07:12:10 UTC, Nordlöw wrote: should not be scanned by the GC. Shouldn't be a problem. What do you mean? I'm talking about an optimization; don't call addRange when we don't need to, because the internal stored `E* _ptr` is maintained manually by calls to `*alloc` and `free`.
Re: When to call GC.{add,remove}Range in containers?
On Monday, 10 October 2016 at 07:12:10 UTC, Nordlöw wrote: should not be scanned by the GC. Shouldn't be a problem.
When to call GC.{add,remove}Range in containers?
Which std.trait should be used to statically check whether I
should call GC.{add,remove}Range on the elements of D containers?
`std.container.array.Array` currently uses `hasIndirections` but
a comment on the same line says it should use `hasPointers`
instead.
containers-em uses
template shouldAddGCRange(T)
{
import std.traits;
enum shouldAddGCRange = isPointer!T || hasIndirections!T || is
(T == class);
}
Quite some inconsistency here.
And what the case `Array!(Array!int))`? The wrapper Array!int
contains contains a non-GC allocate pointer to ints and should
not be scanned by the GC. Do we need another Container-trait for
this? Or do we need to tag pointers with a special attribute that
tells whether it has been allocated by GC or not.
