On Jul 14, 2017, at 8:09 AM, Jeremy Hughes <moon.rab...@virginmedia.com> wrote:
> 
>> On 14 Jul 2017, at 14:40, Steve Christensen <puns...@mac.com> wrote:
>> 
>> On Jul 14, 2017, at 3:50 AM, Jeremy Hughes <moon.rab...@virginmedia.com> 
>> wrote:
>>> 
>>> I’m still not entirely clear on when autorelease pools are used in Swift. 
>>> There is a WWDC video which says that they’re used in code that interfaces 
>>> with Objective-C, but Greg Parker’s comments in this thread indicate that 
>>> autorelease is also used behind the scenes in native Swift code - except 
>>> that in many cases the compiler is able to optimise it out of existence. 
>>> Apple’s Swift book doesn’t mention autorelease.
>> 
>> I think the hazard here is that you are trying to build a mental model of 
>> when to expect autorelease pools (or autorelease behavior in general) and 
>> when not to. Worse, that you might design your code to fit those 
>> expectations.
> 
> Apple’s documentation states that there are times that you do want to 
> consider the memory effects of autorelease pools (and suggests adding your 
> own pools to prevent large accumulations of dead objects during loops) - so 
> knowing when they are used isn’t irrelevant.

What I was getting at is that whether or not an object created by something 
other than your code is in an autorelease pool should be of no concern to you 
(at least with ARC). If your code assigns it to a strong variable, adds it to 
an array, etc., then its retain count will be incremented because your code is 
now becoming a [co-]owner of the object. Whether or not the retain count will 
be decremented someplace else due to an enclosing autorelease pool or some 
other mechanism will not affect that behavior.

If you explicitly create an autorelease pool, such as for reasons that you've 
mentioned above, then you need to be aware that something you created in the 
pool's scope, and want to continue existing beyond the pool's scope, could 
magically disappear when the pool is drained if you're not managing it 
correctly.

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to