Re: mutableBytes Creates Autoreleased Objects
Re: mutableBytes Creates Autoreleased Objects
- Subject: Re: mutableBytes Creates Autoreleased Objects
- From: Quincey Morris <email@hidden>
- Date: Sat, 12 May 2012 12:31:13 -0700
On May 12, 2012, at 10:17 , Ken Thomases wrote:
> That's not necessarily so. And/or requesting the mutableBytes may do the equivalent of retain+autorelease on the NSMutableData.
>
> Consider an inexact analog. The -[NSString UTF8String] method seems to create an autoreleased NSData (or similar object) to hold the UTF-8-encoded C string that it returns. It's not returning the NSData object, obviously, it's just using the autoreleased lifetime to manage the lifetime of the C string.
I think the difference is that for UTF8String, there is an API contract that promises the result will be an object (and it has the lifetime behavior of any returned object that is returned with +0 retain semantics, as the documentation warns).
For mutableBytes, there's no API contract that it's an object at all, or that it has any particular lifetime semantics if it is. If it was an object of some kind in Andrea's testing, that should be regarded as luck. Note that the documentation for mutable bytes *explicitly* warns that it may point to different things in different frameworks releases.
On May 12, 2012, at 10:18 , Charles Srstka wrote:
> Ugh, so you’re saying that ARC isn’t actually as deterministic as we’ve been led to believe?
Indeterminism isn't the problem. Unmarked interior pointers *are*.
> On the headers on my system, bytes and mutableBytes *are* marked that way.
Yes, they're marked on my OS X 10.7 SDK. They're not marked on my iOS 5.1 SDK, which was the one I happened to look at.
This means that the time of deallocation of any private memory object that mutableBytes might refer to is affected by at least the following factors:
1. The optimization level. (Might shorten the compile-time scope of the NSMutableData object by varying amounts.)
2. The SDK in use. (Might keep the compile-time scope of the NSMutableData object longer based on interior pointers, or not.)
3. Whether the internals of NSMutableData use autorelease. (May vary in different frameworks versions, or for NSMutableData objects created with different initializer and/or parameters.)
4. Whether the NSMutableData is autoreleased for any other reason.
There's no free lunch here, unless the interior-pointer-returning methods are known to be marked as such. Then ARC hands out very free lunches indeed. :)
P.S. Hmm. The scope extension from marked interior pointers doesn't really seem to be memory-model specific. I wonder if clang also hands out free lunches to GC code using marked interior pointers. That would be nice.
_______________________________________________
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