Re: CFNetworking and ARC (was: ARC conversion help - CFErrorRef* and NSError**)
Re: CFNetworking and ARC (was: ARC conversion help - CFErrorRef* and NSError**)
- Subject: Re: CFNetworking and ARC (was: ARC conversion help - CFErrorRef* and NSError**)
- From: Roland King <email@hidden>
- Date: Wed, 31 Oct 2012 08:35:24 +0800
On 31 Oct, 2012, at 8:30 AM, Rick Mann <email@hidden> wrote:
>
> On Oct 30, 2012, at 17:27 , Roland King <email@hidden> wrote:
>
>> I must be missing something here. Why can't you just set up your CFSocketContext with CFRetain for the CFAllocatorRetainCallback, CFRelease for the CFAllocatorReleaseCallback and cast the object to the (void*)info paramter with (__bridge void*)yourObject when you put that into the CFSocketContext. Job done, the CFSocket code will call CFRetain() for you during CFSocketCreateConnectedToSocketSignature(), which will retain it before ARC releases the original, and will call CFRelease() when the socket deallocs.
>>
>> You don't want CFBridgingRetain() here because you aren't passing ownership to Core Foundation, you're just giving it the object and it's taking ownership and releasing it again via the retain and release methods you've told it to use in CFSocketContext.
>
> I wrote this based on some Apple sample code, never bothered to learn how to properly use CFSocketContext. Nevertheless, is it okay to CF-manage an NSObject subclass that's not one of Apple's toll-free bridged classes?
>
>
CFRetain() and CFRelease() on a cast-to-void*-or-CFTypeRef NSObject subclass are fine. You can treat an NSObject as a CFTypeRef for those memory management calls, yes.
_______________________________________________
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