Re: GC pros and cons
Re: GC pros and cons
- Subject: Re: GC pros and cons
- From: Greg Guerin <email@hidden>
- Date: Sat, 27 Jun 2009 16:39:32 -0700
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