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

FROM : John Stiles
DATE : Fri Nov 09 19:46:49 2007

On Nov 9, 2007, at 10:33 AM, Clark Cox wrote:

> On Nov 9, 2007 9:54 AM, John Stiles <<email_removed>> 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_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/<email_removed>

This email sent to <email_removed>