> For example, NSString often uses > another allocation internally to hold the string data, and you have no > way to know where that is.
Even if you use initWithBytesNoCopy:, you have no way to know whether some part of the system will need a string in a different encoding and make a copy. (Or make a copy in order perform some other manipulation.) You could take a guess, and try feeding it a UTF-16 buffer. But if even if today's OS doesn't copy the contents somewhere along the line, that's no guarantee about next week's update. Once you make an NSString from your data and send it off to be displayed to the user, you've lost control over whether or not that data gets copied. -- Scott Ribe scott_r...@killerbytes.com http://www.killerbytes.com/ (303) 722-0567 voice _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
