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

FROM : John Stiles
DATE : Fri Nov 09 18:54:55 2007

If you aren't averse to ObjC++, there's always the traditional C++ 
solution for a block of memory that has a controlled lifetime:

   vector<float> myData(size);
   float *myPointer = &myData[0]; // or just use myData directly, it 
will work the same as a C array in the majority of cases

Then myData should last until it falls out of scope. This is easier 
than malloc because you don't have to worry about edge cases where 
you fail to free it properly (e.g. calling return in the middle of a 
function).

Only thing I'm not sure about—if you raise an ObjC exception, I don't 
know if myData would be leaked. Not sure how well ObjC++ exceptions 
handle C++ cleanup.


On Nov 9, 2007, at 7:39 AM, Rick Hoge wrote:

>
> I've been testing some of our older libraries under GC, and have 
> found one coding pattern (that may well have been bad practice 
> anyway) that really does not work well under GC.
>
> I used to use convenience constructors for NSMutableData objects as 
> a kind of lazy replacement for malloc.
>
> That is, an assignment like this:
>
>  float *myPointer = [[NSMutableData dataWithLength:size*sizeof
> (float)] mutableBytes]; // Memory freed at end of event loop
>
> could be used in place of
>
>  float *myPointer = (float*)malloc(size*sizeof(float)); // Needs a 
> free() later
>
> The advantage of the first, under traditional memory management, 
> was that the memory would presumably be cleaned up at the end of 
> the current event loop (whereas the second would require a malloc 
> downstream in the code).
>
> It seems like this (not surprisingly) doesn't work reliably under 
> GC, as the collector obviously has no way of knowing that you are 
> later looking at the memory originally addressed by myPointer.  It 
> keeps track of objects and not pointers.
>
> One possible solution is to replace the first assignment with
>
>  NSMutableData *myData = [NSMutableData dataWithLength:size*sizeof
> (float)];
>
> and use
>
>  ((float*)[myData mutableBytes])  in place of myPointer.
>
> The other option is to just use malloc/free pairs - which I don't 
> mind to a certain extent but the autoreleased convenience 
> constructor was nice when there were a lot of little chunks of data 
> to allocate which would not be needed after the end of the event 
> loop.  I guess the concept of a convenience constructor no longer 
> has the same significance it did pre-GC.
>
> As there are probably better ways of approaching this kind of 
> situation, I'd be interested in any suggestions or comments.  The 
> way I was doing it before was probably just bad...  still this 
> explained a few spooky bugs in one of our apps under GC.
>
> Cheers,
>
> Rick
> _______________________________________________
>
> Cocoa-dev mailing list (<email_removed>)
>
> 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/jstiles%
> 40blizzard.com
>
> This email sent to <email_removed>