Improving DIP74: functions borrow by default, retain only if needed

Steven Schveighoffer via Digitalmars-d digitalmars-d at puremagic.com
Fri Feb 27 13:33:51 PST 2015


On 2/27/15 4:15 PM, Andrei Alexandrescu wrote:
> On 2/27/15 12:34 PM, Steven Schveighoffer wrote:
>> On 2/27/15 3:30 PM, Steven Schveighoffer wrote:
>>
>>> void main()
>>> {
>>> C c = new C; // ref counted class
>>> C2 c2 = new C2; // another ref counted class
>>> c2.c = c;
>>> foo(c, c2);
>>> }
>>
>> Bleh, that was dumb.
>>
>> void main()
>> {
>>     C2 c2 = new C2;
>>     c2.c = new C;
>>     foo(c2.c, c2);
>> }
>>
>> Still same question. The issue here is how do you know that the
>> reference that you are sure is keeping the thing alive is not going to
>> release it through some back door.
>
> Thanks! In ARC, there are autorelease pools that keep at least one
> reference to the objects they own. I think that's what they are for.

No, that's not what they are for. They are for returning data without 
having to worry about the receiving function needing to release. This 
was really important for manual reference counting. Otherwise, you would 
always have to return a value with it's count at 1, and put the onus on 
the receiving function to store the result and release it after using. 
One-liners would turn into huge nests of temporary variables.

I believe autorelease pools are not needed for ARC, but are maintained 
because much Objective-C code contains MRC, and that protocol needs to 
be supported. I used them a lot in my Objective-C code. With ARC you can 
create autorelease pools, but you never did any autoRetain manually, the 
ARC system did it. Creating the pool just allows you to scope where data 
should be released. Otherwise, you are adding it to the event loop pool 
which is only released after an event is done processing.

-Steve


More information about the Digitalmars-d mailing list