Re: A coding pattern that does not work under Garbage Collection

FROM : Rick Hoge
DATE : Fri Nov 09 20:35:45 2007

>> (Not a GC expert...)


But you read the manual better than I did :)

>> No, I think you're still screwed. Since you can't know how NSData 
>> manages its bucket of bytes, you need to make sure the NSData 
>> object stays around for as long as you want to work with the bytes.
>>
>> The salient point was that no one kept a reference to the object 
>> which owned the bytes you were pointing at, and when the object got 
>> collected as a result, it's internal storage also went away.
>>
>> Really not so different from the autorelease case, except there you 
>> were guaranteed the lifetime of the parent autorelease pool. In a 
>> GC world the collector will collect unreferenced objects when it 
>> gets around to it, so you better keep a strong reference to the 
>> object for as long as you need it.

>
> Jim is correct and this is an unfortunate edge case that there 
> wasn't time to address in Leopard.  Fortunately, the solution is 
> straight forward;  keep the NSData object around for as long as you 
> need its memory to stick around.


This is not a problem - just good to be aware of.

Regarding NSAllocateCollectible, just to make sure I am not 
misunderstanding - I can allocate memory like the example below?

  __strong int* tempInt = (__strong 
int*)NSAllocateCollectable(sizeof(int), NSScannedOption);

and rely on the garbage collector to figure out when I've reached a 
point where tempInt could no longer possibly be used to access that 
memory?  so no leaks even without a free()?

Thanks for this and the other very informative replies to this post.

Rick