Re: A coding pattern that does not work under Garbage Collection
Re: A coding pattern that does not work under Garbage Collection
- Subject: Re: A coding pattern that does not work under Garbage Collection
- From: John Stiles <email@hidden>
- Date: Fri, 9 Nov 2007 09:54:55 -0800
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@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:
40blizzard.com
This email sent to email@hidden
_______________________________________________
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