Re: How determine if file is in Trash, given Path or Alias
Re: How determine if file is in Trash, given Path or Alias
- Subject: Re: How determine if file is in Trash, given Path or Alias
- From: Ken Thomases <email@hidden>
- Date: Tue, 2 Jun 2009 23:41:18 -0500
On Jun 2, 2009, at 9:21 PM, Michael Ash wrote:
The NSString methods are unlikely to be problematic here. NSData is
troublesome because it's returning an internal pointer. In other
words, it's a pointer to some memory that it already holds on to in
the normal course of things, and it gives you that pointer. Since it
manages this memory explicitly, its lifetime is linked to the lifetime
of the NSData object.
The NSString case is quite different. It's (probably?) not an internal
pointer at all. Instead, it's newly allocated memory being returned to
you. The NSString (probably?) does not hold a pointer to this memory,
and thus its lifetime is not linked to the lifetime of the NSString
object that it came from. When you ask an NSString for its UTF8String,
it (probably?) has to create that from scratch by converting its
internal storage, unlike NSData which just returns its internal
storage directly.
I put all of those "probably" things up there because it is at least
conceivable to have an NSString where this *is* an internal pointer,
so you might not want to count on this being true. However I'd judge
it to be pretty unlikely. Wouldn't hurt to make your code safe against
it even so.
I'm not so sure about "unlikely" and "probably", as opposed to merely
"possibly". The thing is, it might very well be internal to some
object, even if that object is not the string specifically.
In the non-GC case, the most likely way for NSString to return a C
string that has a lifetime of the autorelease context is for NSString
to create an autoreleased NSData to hold the properly encoded bytes,
and then return the -bytes of that data object. Even if that's not
the exact way NSString does it, in the non-GC case there's really no
way to implement an "autoreleased buffer" that doesn't involve an
interior pointer of something. Something has to manage the lifetime
of that buffer, after all, and it's probably an object in the
autorelease pool.
Apple may have changed the implementation as it implemented GC, so
that NSString allocates the data buffer from the collector, but it may
have just left the implementation alone. The non-GC approach still
works in a GC environment, except for the interior pointer issue.
Regards,
Ken
_______________________________________________
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