digitalmars.D.learn - When to call GC.{add,remove}Range in containers?
- =?UTF-8?B?Tm9yZGzDtnc=?= (18/18) Oct 10 2016 Which std.trait should be used to statically check whether I
- Kagamin (2/3) Oct 10 2016 Shouldn't be a problem.
- =?UTF-8?B?Tm9yZGzDtnc=?= (5/8) Oct 10 2016 What do you mean?
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.
Oct 10 2016
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.
Oct 10 2016
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: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`.should not be scanned by the GC.Shouldn't be a problem.
Oct 10 2016