> I’m not sure I’d want that either, though. If the original string was a
> 200-page dissertation and you took a one-word substring from it, it doesn’t
> seem reasonable to keep the whole 200-page dissertation all in RAM just to
> keep the one-word substring around.
But that's a very old probl
On Mar 5, 2012, at 6:40 PM, Wade Tregaskis wrote:
> Perhaps the only 'correct' solution to this problem is to fall back to the
> CFString level, where you can pass a custom CFAllocator to e.g.
> CFStringCreateWithBytesNoCopy(). That way the lifetime is effectively
> managed by the CFString, so
On Mar 3, 2012, at 3:03 PM, Eli Bach2 wrote:
>
> On Mar 3, 2012, at 12:15 PM, Jens Alfke wrote:
>
>> I filed a bug report* saying that this substring optimization shouldn’t be
>> used if the source string uses an external buffer, just as it shouldn’t if
>> the source string is mutable. They fi
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
Perhaps the only 'correct' solution to this problem is to fall back to the
CFString level, where you can pass a custom CFAllocator to e.g.
CFStringCreateWithBytesNoCopy(). That way the lifetime is effectively managed
by the CFString, so it should behave correctly in all cases.
'course, the imp
On Mar 3, 2012, at 12:15 PM, Jens Alfke wrote:
> I filed a bug report* saying that this substring optimization shouldn’t be
> used if the source string uses an external buffer, just as it shouldn’t if
> the source string is mutable. They fixed it, but some people there argue that
> their origi
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
Hit send too soon...
> The documentation of -[NSData initWithBytesNoCopy:length:freeWhenDone:] and
> of -[NSString initWithBytesNoCopy:length:encoding:freeWhenDone:] is unclear
> about the case where freeWhenDone is NO. The data/string object then does not
> take ownership of the memory buffer,
> The documentation of -[NSData initWithBytesNoCopy:length:freeWhenDone:] and
> of -[NSString initWithBytesNoCopy:length:encoding:freeWhenDone:] is unclear
> about the case where freeWhenDone is NO. The data/string object then does not
> take ownership of the memory buffer, so the question is: H
