std.experimental.collection.functional.slist

Ivan Timokhin via Digitalmars-d digitalmars-d at puremagic.com
Fri Jun 19 13:09:41 PDT 2015


Correct me if I'm wrong, but it seems that the GC is unaware of any memory
coming from an allocator (unless it's a GCAllocator, of course), so it won't
scan it. If that's the case, that's bound to cause problems if T has
indirections.

On Thu, Jun 18, 2015 at 11:32:05PM +0000, Andrei Alexandrescu wrote:
> First pass illustrating the basic data layout:
> 
> http://dpaste.dzfl.pl/0d4a589ad6f5
> 
> Code is obviously barebones but passes tests and works with allocators.
> 
> Notes:
> 
> * I managed to not store one allocator per node, but there's one 
> allocator per range. That's needed if we want "orphan ranges" to work, 
> i.e. ranges that survive the list they came from. This is a clasic 
> convenience vs. efficiency thing.
> 
> * There's a refcount per node because any given node may belong to 
> multiple lists.
> 
> * Refcounting is interesting because many nodes are only used by the 
> previous node. So destroying a list is... funny. Never saw or wrote code 
> like this previously. See nukeTransitively.
> 
> All in all things seem convex. Please destroy appropriately.
> 
> 
> Thanks,
> 
> Andrei


More information about the Digitalmars-d mailing list