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