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 17:42:35 -0700
I figured the details out and taught my staff to use the techniques.
it isn't that hard. I learned what I needed to know from the objc 2.0
manual and a little bit of trial and error.
The critical thing to watch are the exceptions since those are
incompatible in legacy mode. You just have to understand that a C++
exception won't trip the objc catch machinery and an objc exception
won't trip the C++ catch machinery. Once you understand that, you
watch for things, such as @synchronized that rely on those mechanisms
to function correctly.
I myself didn't hit the @sychronized problem because I don't use
@synchronize. But, if I had, it would have been pretty obvious if the
backtrace showed the app was stuck in a a lock in the @synchronized
after a C++ exception occurred.
I like C++. I find it an incredibly useful language. I like the
mentality behind the design of C++ & STL. I'm capable of using it
quite effectively. So, that is the tool I use. It isn't perfect, but
I have never seen a developer tool that is perfect.
If you don't like C++ or it isn't an option for you for some reason,
then my technique isn't for you.
BTW: keep in mind that the exception gotchas go away on iphone & 64
bit MacOSX. In a few years, once leopard and 32 bit macs are mostly
retired in the marketplace, one can remove the macros and just catch
NSException pointers directly. kudos to the objc 2.0 guys for adopting
the C++ exception system.
Here are the macros if you want to see them. I need to adjust them for
iphone, but I''l deal with that once I actually start building iphone
products.
#ifdef __OBJC__
#ifndef __LP64__
#define OBJC_EXCEPTION_TRY @try {
#define OBJC_EXCEPTION_CATCH } @catch(id theExcpPtr) { throw
theExcpPtr;}
#define OBJC_EXCEPTION_CATCH_IGNORE } @catch(id theExcpPtr) {}
#else
#define OBJC_EXCEPTION_TRY
#define OBJC_EXCEPTION_CATCH
#define OBJC_EXCEPTION_CATCH_IGNORE
#endif
#endif
an example of using them....
-(void)writeLogToFile
{
boost::mutex::scoped_lock tmpLock(statFileWriteMutex);
OBJC_EXCEPTION_TRY
[mIndexedDocumentPathsAndTimesSPtr.get()
writeToFile:mLogPathSPtr.get() atomically:YES];
[mFailedIndexedDocumentPathsAndTimesSPtr.get()
writeToFile:mFailedLogPathSPtr.get() atomically:YES];
OBJC_EXCEPTION_CATCH
}
On Jun 27, 2009, at 4:39 PM, Greg Guerin wrote:
James Gregurich wrote:
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.
Is there a way for other developers to use your approach, or do they
have to reinvent it for themselves? Are the rules and restrictions
written down (e.g. "Don't use @synchronized")? Better yet, are the
restrictions enforceable at compilation? Are all the macros,
classes, and dependencies (e.g. boost) available in a single
location? Are there risks of ad hoc incompatibilities arising due
to multiple reinvention (assuming each developer is expected to
reinvent)?
I ask this in all honesty, with no intent of sarcasm or irony. Even
if I personally have no intention of using it, it seems to me that
any approach is valuable mainly to the extent others can use it
without having to recreate it from scratch, without causing
compatibility problems. Otherwise it's just an individual
productivity tactic, and any experienced developer probably already
has plenty of those to work from.
Speaking from my own experience, one person's productivity tactic
can be another person's worst nightmare. One early example: the
source for the original Bourne shell. It was written with Pascal-
like (or shell-like) macros that redefined if/else, loops, blocks,
etc. For example, C code "if (x) { ... }" would be written as "IF x
THEN ... FI", where IF, THEN, FI etc. are all macros. While I can
appreciate the cleverness of this, it was one of the worst things to
maintain I've ever experienced. This did not make the shell itself
any less useful or powerful: it was a great improvement over its
predecessor, and I did plenty of things with it's extended
capabilities. It just made it horrible to have to fix bugs in it,
or, far worse, add new capabilities.
It seems to me one advantage of the current GC is it's a documented
and more or less standardardized set of rules and behaviors that any
developer can use, and can also deploy in reusable libraries. A
given library may be GC-only, GC-capable, or GC-incompatible, but
there is still a way to specify this for a library, and it is
enforced by the tools.
Also, GC works without requiring C++. There may be reasons why C++
isn't used in a particular situation, or can't be used, so the fact
that your approach seems to require C++ automatically precludes it
from those situations.
-- GG
_______________________________________________
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