Thanks, I'm just surprised that this common, often cited example is broken.
http://books.google.co.uk/books?id=bwQY3_5FMg8C&pg=PA775&lpg=PA775&dq=beginBackgroundTaskWithExpirationHandler&source=bl&ots=aMuw5-hiP6&sig=NFKFDhaPw41KnfOo1n7Z_OaJflM&hl=en&sa=X&ei=T-s_T76JEaOl0AW0y-iPDw&ved=0CGoQ6AEwCTgK#v=onepage&q=beginBackgroundTaskWithExpirationHandler&f=false That's an awful lot of broken code. On 18 February 2012 17:23, Fritz Anderson <fri...@manoverboard.org> wrote: > On 18 Feb 2012, at 7:41 AM, steven Hooley wrote: > >>> The same issue came up again later the same day: >>> >>> __block UIBackgroundTaskIdentifier bti = [[UIApplication >>> sharedApplication] >>> beginBackgroundTaskWithExpirationHandler: >>> ^{ >>> [[UIApplication sharedApplication] endBackgroundTask:bti]; >>> }]; >>> >>> Without __block, bti is invalid, and you won't find that out easily because >>> it's unlikely that you'll actually expire. :) m. >> >> Can this be right? > > If I understand why you're mystified, consider this, without the __block > declaration. > > - bti starts as junk. > > - The block is instantiated, and captures the junk _value_ (because it's not > a __block variable) of bti. > > - The beginBackgroundTask… method creates the background task identifier. > > - That identifier is then assigned to bti. bti is no longer junk, but that > does the block no good, because it's already captured the junk value. > > > If bti is declared __block, the block captures (notionally) a _reference_ to > bti. It doesn't evaluate bti until it executes, which will be after the > assignment. > > — F > _______________________________________________ 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
