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