Re: __bridge_transfer on a method return value
Re: __bridge_transfer on a method return value
- Subject: Re: __bridge_transfer on a method return value
- From: Quincey Morris <email@hidden>
- Date: Thu, 10 May 2012 01:35:42 -0700
On May 9, 2012, at 23:07 , Roland King wrote:
> I'm using CFURLCreateStringByAddingPercentEscapes() because the NSString version leaves '+' signs unescaped. If I used it directly in code I'd either CFRelease it, or if assigned to an NSString, __bridge_transfer it. However I want it as the return value of a method. So I wrote this
>
> +(NSString*)webEncodedString:(NSString *)string
> {
> CFStringRef retval = CFURLCreateStringByAddingPercentEscapes( NULL, (__bridge CFStringRef)string, NULL, CFSTR( "!*'();:@&=+$,/?%#[]" ), kCFStringEncodingUTF8 );
> return( __bridge_transfer NSString*)retval;
> }
>
> My confusion comes from not knowing whether this function now returns an object with a +1 refcount or not. If it does it needs to be renamed to have new or copy etc in the method name, or annotated properly to show that. My first thought was that yes the transfer means the return value has a +1 refcount. Then I wondered if the __bridge_transfer transfers ownership to some temporary inside the method which will be released as it goes out of scope and do the job so all retains/releases are balanced out and the return value does not have an extra retain on it. I suppose if I wrote the same thing like this it highlights the difference
>
> +(NSString*)webEncodedString:(NSString *)string
> {
> CFStringRef retval = CFURLCreateStringByAddingPercentEscapes( NULL, (__bridge CFStringRef)string, NULL, CFSTR( "!*'();:@&=+$,/?%#[]" ), kCFStringEncodingUTF8 );
> NSString *temp = (__bridge_transfer)retval;
> return temp;
> }
>
> Here it would seem the ownership passes to temp, which goes out of scope at the end of the method and would release, after I assume some retains/autoreleases are done to ensure the object lives long enough to make it back to the caller, but still balanced.
You're correct that the two versions are equivalent at the point of return. I believe the balance sheet looks like this in the first case:
+1 assumed by the bridge transfer to have already happened
-1 from completing the expression containing the bridge transfer
+1 to the return expression result
-1 from returning
Thus the net retain count is 0, but the return statement ensures that the object survives at least until the caller has a chance to retain it. This might be via an autorelease, or may be something more optimal.
The balance sheet for the second case looks like this:
+1 assumed by the bridge transfer to have already happened
-1 from completing the expression containing the bridge transfer
+1 from the assignment to temp
+1 to the return expression result
-1 from temp going out of scope
-1 from returning
So the net is still 0.
This is all on the basis of:
http://clang.llvm.org/docs/AutomaticReferenceCounting.html
in sections 3.2.3, 3.2.4 and 4.2.
The only differences that calling this method 'newWebEncodedString' would make (AFAIK) are that the return value would never need to be autoreleased, the final release from the return statement wouldn't happen, and the caller would have slightly different code because of the guaranteed +1 retain count.
_______________________________________________
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