Escaping the Tyranny of the GC: std.rcstring, first blood

Dmitry Olshansky via Digitalmars-d digitalmars-d at puremagic.com
Wed Sep 24 03:35:27 PDT 2014


23-Sep-2014 16:17, Manu via Digitalmars-d пишет:
> On 23 September 2014 17:17, Dmitry Olshansky via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> 23-Sep-2014 10:47, Manu via Digitalmars-d пишет:
>>>
>>> On 23 September 2014 16:19, deadalnix via Digitalmars-d
>>> <digitalmars-d at puremagic.com <mailto:digitalmars-d at puremagic.com>> wrote:
>>>
>>>      On Tuesday, 23 September 2014 at 03:03:49 UTC, Manu via
>>>      Digitalmars-d wrote:
>>>
>>>          I still think most of those users would accept RC instead of GC.
>>>          Why not
>>>          support RC in the language, and make all of this library noise
>>>          redundant?
>>>          Library RC can't really optimise well, RC requires language
>>>          support to
>>>          elide ref fiddling.
>>>
>>>
>>>      I think a library solution + intrinsic for increment/decrement (so
>>>      they can be better optimized) would be the best option.
>>>
>>>
>>> Right, that's pretty much how I imagined it too. Like ranges, where
>>> foreach makes implicit calls to contractual methods, there would also be
>>> a contract for refcounted objects, and the compiler will emit implicit
>>> calls to inc/dec if they exist?
>>
>>
>> In my imagination it would be along the lines of
>> @ARC
>> struct MyCountedStuff{ void opInc(); void opDec(); }
>
> Problem with this is you can't make a refcounted int[] without
> mangling the type,

Is that a problem at all? Why should int[] some how become ref-counted. 
I constantly at loss with strange edge requirements in your questions. 
Why "mangling" a type is bad?

>and you also can't allocate a ref counted 3rd-party
> type.

Ref-Counted!T or make a wrapper that does call some 3-rd party opInc/opDec.
>
>>> Then we can preserve the type of things, rather than obscuring them in
>>> layers of wrapper templates...
>>
>>
>> This would be intrusive ref-counting which may be more efficient.
>
> Perhaps I'm not clear what you mean by intrusive/non-intrusive?
>

Embed the count vs add a count along the user type.
A use case is for intrusive is to stuff a ref-count into the padding of 
some struct. A non-intrusive is shared_ptr<T> of C++.


-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list