On 3 Mar 2012, at 12:24 PM, Jens Alfke wrote: > On Mar 3, 2012, at 11:28 AM, Dave Keck wrote: > >> The buffer needs to remain intact until the NSString/NSData object is >> deallocated. > > True; but a strict interpretation of this is that the buffer can _never_ be > destroyed, because you can never predict with 100% accuracy when an object is > going to be deallocated. (as discussed in all those “why -retainCount is > useless for debugging” threads.)
The other big use I have for -...withBytesNoCopy:, though, is referencing a statically allocated buffer, like a big table of data that's in my text segment. In that case, I *do* want the implementation to assume that the buffer is available indefinitely and make use of it as much as it can. In the rare situation that I have a buffer with a finite lifetime and don't want the overhead of copying into a malloc buffer (memory-to-memory copies don't seem to show up on my profile data much any more), I've made a custom NSData subclass to hold it. That instance is properly retain-counted until the last reference to the buffer goes away, and it can do whatever cleanup is appropriate. This seems like the Right Way To Do It to me, though it does seem like an overly large hammer for a small problem. _______________________________________________ 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
