My take: __bridge means 'do not transfer the retain count of <whatever on the RHS> to the LHS'. If the RHS involves some kind of create or new, then you'll get a leak since ARC won't release it.
__bridge_transfer means 'transfer the retain count of <whatever on the RHS> to the LHS'. If the RHS involves some kind of create or new, then you can just rely on ARC, or you'll have to release via CFRelease(). Since CFStringGetIntValue() does not return an object, you don't need __bridge at all - there's no 'retaining' going on behind the scenes. ARC sees you're getting back a scalar, and the compiler sees no ambiguity or error. But CGImageSourceCreateWithURL() includes the keyword 'create' - so the object you get back has a retain count of 1. ARC will insist that you cast with __bridge or __bridge_transfer. Under ARC, you have to let the compiler know whether you are taking responsibility (__bridge_transfer, ARC will release when it goes out of scope), or not (__bridge, followed by a CFRelease()) for ultimately releasing the newly created object. I'm probably wrong, but this is how I've been working with ARC, based on the docs and blogs. Rob On Jul 27, 2013, at 2:31 PM, Matt Neuburg <m...@tidbits.com> wrote: > I feel like I've asked this before, but I don't feel I'm grasping the answer. > Why don't these work the same way under ARC: > > NSString* answer = @"42"; > int ans = CFStringGetIntValue((CFStringRef)answer); > > and > > NSURL* imageSource = [NSURL new]; > CGImageSourceRef src = > CGImageSourceCreateWithURL((CFURLRef)imageSource, nil); > > The first one compiles (with no explicit __bridge). The second one doesn't; > you must say __bridge explicitly. But why? They look completely parallel to > me. > > The mystery is compounded by the fact that if you omit the cast entirely in > the first example, the compiler claims that you need a bridged cast. But you > don't; you just need a cast. That feels like a bug; if a mere cast is > sufficient, the compiler should say so (and Fix-It should offer it as a > possible fix). > > m. > > -- > matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ > pantes anthropoi tou eidenai oregontai phusei > Programming iOS 6! http://shop.oreilly.com/product/0636920029717.do > RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html > TidBITS, Mac news and reviews since 1990, http://www.tidbits.com > > > _______________________________________________ > > 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/robmartin%40frontiernet.net > > This email sent to robmar...@frontiernet.net _______________________________________________ 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
