Re: Garbage collected and non-garbage collected
Re: Garbage collected and non-garbage collected
- Subject: Re: Garbage collected and non-garbage collected
- From: Marcel Weiher <email@hidden>
- Date: Thu, 7 May 2009 09:57:05 -0700
[catching up with my cocoa-dev backlog]
On Mar 10, 2009, at 20:36 , Michael Ash wrote:
On Tue, Mar 10, 2009 at 2:47 PM, Robert Mullen <email@hidden>
wrote:
Too little resource, too little experience, too little return. The
first two
are because this is a skunk works type corporate project that
basically has
myself (an ex-.NET and general Windows coder) as it's resource so is
constrained by me. The third is because I don't see sufficient gain
to doing
all the memory management myself. GC systems have become efficient
enough in
our modern world that I think manual memory management has become
pretty
specialized and out of place in 80% of desktop applications.
Certainly there
is the other 20% of high performance and real time situations but
mine is
basically a pretty face on a database. Anybody want to argue the
other
direction? I am always willing to learn.
IMO you're right but also asking the wrong question.
You shouldn't be asking whether GC is worthwhile for desktop apps, but
whether *Cocoa's* GC is. They are not, unfortunately, the same
question. While Cocoa's GC is quite good given the constraints it
lives in, those constraints cause many unfortunate problems which
don't exist in other collectors. Some are in the collector itself
(don't take the address of a global pointer-to-object variable if you
don't like to crash), and some are in the frameworks (NSData has
hidden gotchas, NSInvocation doesn't keep strong references to message
arguments, and many other weird problems). Apple did a good job with
the GC given the constraints they were under (adding GC to a C runtime
environment is Not Easy) but there are still quite a few shortcomings
there.
Well said! In addition, retain/release is not the same as manual
memory management, at worst it's semi-automatic. Taking both that
fact and what Mike said means that the common perception:
"modern/managed" GC=Cocoa GC
<---------------------------------------------> manual memory
management=Cocoa RC
isn't really true. The actual state of affairs is something more
along the lines of the following:
"modern/managed" GC <-----> Cocoa GC <---> Cocoa RC <--------->
manual memory management
Properties or accessor macros close the gap even further, because now
you don't have to write any of the memory management code inside
accessors, getting us to something like
Cocoa GC <> Cococa RC
In my experience, that removes virtually all of the explicit memory
management except for the releases in -dealloc.(1), and once you're
there, wether the quirks of the GC or the slight extra work of the RC
is the bigger issue becomes pretty much a tossup depending on your
circumstances.
You may still be right that going with GC and fixing this stuff up is
the best use of your time. I won't argue with that. I just wanted to
point out that it's not as simple as saying "modern GCs are good
enough for the job now" since the GC you have isn't exactly the GC
you'd have in a more "managed" environment.
What he said.
Marcel
(1) I have code that automates releasing objects in dealloc, but the
burden is so light that I never bother to use it...
_______________________________________________
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