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 10:46:49 -0800
On Nov 9, 2007, at 10:33 AM, Clark Cox wrote:
On Nov 9, 2007 9:54 AM, John Stiles <email@hidden> wrote:
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.
In 32-bit, it isn't handled at all (you'll have to catch the Obj-C
exceptions, destroy the vector yourself, and rethrow the exception).
In 64-bit, Obj-C exceptions *are* C++ exceptions (and vice-versa), so
all is well (all the normal C++ stack unwinding/destructor calling
goodness happens)
It's a bit of a bummer how many of the ObjC runtime improvements
aren't making it back to 32-bit, isn't it?
I know, binary compatibility and all, but if there was a way to opt-
in, that would sure be nice. Our apps aren't going 64-bit any time
soon, but I'd appreciate improved exception handling (and I guess I
could give up posing ;) )._______________________________________________
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