Idea #1 on integrating RC with GC
Sean Kelly
sean at invisibleduck.org
Tue Feb 4 18:08:32 PST 2014
On Wednesday, 5 February 2014 at 01:52:48 UTC, Adam Wilson wrote:
> On Tue, 04 Feb 2014 17:12:37 -0800, deadalnix
> <deadalnix at gmail.com> wrote:
>
>> On Tuesday, 4 February 2014 at 23:51:35 UTC, Andrei
>> Alexandrescu 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.
>>>
>>> Now, what if someone doesn't care about the whole RC thing
>>> and aims at convenience? There would be a method .toGC that
>>> just detaches the slice and disables the reference counter
>>> (e.g. by setting it to uint.max/2 or whatever).
>>>
>>> Then people who want reference counting say
>>>
>>> auto x = fun();
>>>
>>> and those who don't care say:
>>>
>>> auto x = fun().toGC();
>>>
>>>
>>> Destroy.
>>>
>>> Andrei
>>
>> RC need GC to collect loops. So you want to have the GC at the
>> lowest level.
>>
>> That being understood, I'd rather connect things the other way
>> around.
>>
>> auto x = foo();
>> auto x = foo().toRC();
>
> The ARC crowd is going to hate this because it's still a GC
> allocation then you hook it to RC. So they can still have
> random GC pauses.
GC.disable. Just saying.
More information about the Digitalmars-d
mailing list