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