Re: GC pros and cons
Re: GC pros and cons
- Subject: Re: GC pros and cons
- From: James Gregurich <email@hidden>
- Date: Sat, 27 Jun 2009 08:40:43 -0700
1) I have convenience macros that @catch and throw NSExceptions for
the legacy 32 bit environment. I don't allow legacy objc exceptions to
propagate out of code blocks.
2) I don't use @synchronize. I use boost::thread::mutex so that I have
one consistent, standard locking API throughout my codebase. good
point on @synchronize. I'll be careful to watch out for it.
3) I don't allow exceptions of any kind to propagate into alien
code....particularly the cocoa runtime.
basically, my general approach is to map objc concepts and
idiosyncrasies into the C++ environment....making use of the useful
features of C++ to solve some of the problems with cocoa development.
I've been quite happy with the results in general.
On Jun 26, 2009, at 9:27 PM, Michael Ash wrote:
Normally this would be a silly nitpick, but given the context of the
discussion, I think it's important to mention.
Your code is *not* completely exception-safe in Objective-C++ on the
Mac 32-bit runtime.
On this runtime (but fortunately not on the "modern" runtime found on
the iPhone and 64-bit processes on the Mac) the Objective-C exception
model is *not* unified with the C++ exception model. This means that
throwing an Objective-C exception through this code will not invoke
the objects' destructors and thus will not deallocate your resource.
Now, Objective-C exceptions are fairly rare and most Cocoa programmers
treat them as programming errors to be fixed rather than runtime
errors to be handled, but it's still something that ought to be kept
in mind.
The same goes for throwing C++ exceptions through Objective-C code.
Objective-C doesn't have destructors, but for example you will not
unlock the lock held in a @synchronized block, and various other
things can go wrong. In general, you should keep things well separated
and just not allow exceptions to be thrown through code from the
"other" language.
Mike
_______________________________________________
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
_______________________________________________
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