Re: blocks and retaining CoreFoundation objects
Re: blocks and retaining CoreFoundation objects
- Subject: Re: blocks and retaining CoreFoundation objects
- From: Fritz Anderson <email@hidden>
- Date: Wed, 10 Aug 2011 08:39:21 -0500
On 9 Aug 2011, at 12:05 PM, David Duncan wrote:
> On Aug 8, 2011, at 11:43 PM, Roland King wrote:
>
>> After a bit of googling I came across some posts which explained Block_Copy() would treat a variable adorned with __attribute__((NSObject)) similarly to NSObjects and retain them. So changing the method signature to this
>>
>> -(void)convert:(__attribute__((NSObject))CGImageRef)image withBlock:(ImageResizedBlock)callbackBlock
>>
>> appears to do the right thing in my testing, the CGImageRef is CFRetain()ed when the block is enqueued and I assume CFRelease()d later. I prefer this syntax, as I find it self-documenting;
>>
>> I can't find anywhere apart from blog posts and the block specification itself which says this works. Does anyone know if it's officially supported, for gcc and clang and something that apple is likely to support going forward into ARC
>
> The ARC specification defines a "retainable pointer" as including those pointers that have the __attribute__((NSObject)) decoration, so this should behave as expected under ARC. <http://clang.llvm.org/docs/AutomaticReferenceCounting.html#objects>
I am curious, though, in that CGImageRef is not toll-free bridged to a Foundation class. I had the impression that the API contract was that only bridged CF classes were guaranteed to implement reference-counting methods. The clang document I read seemed to say that the purpose of __attribute__((NSObject)) was to reassure the compiler that the argument type was an alias for an NSObject subclass.
At the page you cite, I see:
> A retainable object pointer is either a null pointer or a pointer to a valid object. [Further qualifications.] ... Otherwise ARC does not enforce the Objective-C type system as long as the implementing methods follow the signature of the static type. It is undefined behavior if ARC is exposed to an invalid pointer.
>
> For ARC's purposes, a valid object is one with well-behaved retaining operations. Specifically, the object must be laid out such that the Objective-C message send machinery can successfully send it the following messages:
>
> • retain, taking no arguments and returning a pointer to the object.
> • release, taking no arguments and returning void.
> • autorelease, taking no arguments and returning a pointer to the object.
I believe the OP when he says it works in his setup, but I wonder if the API promises it will always work.
Have I missed something?
— F
_______________________________________________
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