Idea #1 on integrating RC with GC

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Feb 4 20:13:10 PST 2014


On 2/4/14, 4:01 PM, Steven Schveighoffer wrote:
> On Tue, 04 Feb 2014 18:51:35 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> Consider we add a library slice type called RCSlice!T. It would have
>> the same primitives as T[] but would use reference counting through
>> and through. When the last reference count is gone, the buffer
>> underlying the slice is freed. The underlying allocator will be the GC
>> allocator.
>
> Doesn't that mean it lives in the GC heap and is scanned along with all
> the other data in the GC heap (and triggers GC cycles)? What is the
> benefit?

GC.free is the benefit.

> Shouldn't the default be what is expected now? That is, I don't want to
> have to change all my code to return RCSlice!T instead of T[]. I admit,
> I don't know how that would work...

Me neither.


Andrei




More information about the Digitalmars-d mailing list