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
