Re: ARC and autorelease pools
Re: ARC and autorelease pools
- Subject: Re: ARC and autorelease pools
- From: Kevin Meaney <email@hidden>
- Date: Mon, 17 Feb 2014 09:47:04 +0000
Thanks to Marcel, John McCall, and Clark Smith Cox III for addressing the question I was trying to ask, apologies to others that the question was unclear.
So it seems that because ARC provides compatibility between ARC and non-ARC code unlike how garbage collection worked with duplicated frameworks is part of or even the main reason we can't get rid of autorelease.
My response to Roland's first reply to this thread was incorrect. I had forgotten the reason why I new that class methods like stringWithFormat return an autoreleased object. When I first learnt ARC in May last year I wrote a blog post covering my experiments of when an object stays alive and when it doesn't. I hadn't just assumed, I'd forgotten why I new.
In terms of crossing boundaries I find the result of TestArc9() interesting when passing a weak pointer into a function.
The last line of output from each test routine is at the end of the blog post if you want to test your understanding.
http://blog.yvs.eu.com/2013/05/experimental-arc/
Kevin
On 17 Feb 2014, at 08:08, Marcel Weiher <email@hidden> wrote:
>
> On Feb 17, 2014, at 2:08 , Clark Smith Cox III <email@hidden> wrote:
>
>>> I didn't say take them out. I said why do they need to return an autoreleased object.
>>
>> Because they always have, and their semantics cannot be changed without breaking decades worth of non-ARC code.
>
> Sort of like the way GC did, where you had to have 2 versions of every framework, the GC version and the non-GC version. If you had 2 versions of every framework and the compiler enforced a no autorelease rule, then you could have what you want.
>
> However, one of the big points of ARC was to not require 2 versions of every framework, but instead provide compatibility between ARC and non-ARC code. Therefore all the old requirements for autorelease, which have been explained so well by various posters, apply.
>
> Cheers,
>
> Marcel
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden