Thomas Davie <tom.da...@gmail.com> schrieb am 28.06.2009 18:07:04:
> On 28 Jun 2009, at 17:47, Konrad Neitzel wrote:
> > But a garbage collector must be able to detect an object which
> > memory can / must be released. And for all this, the system has to
> > do some work.
> As must your program do if it keeps track of memory manually. Are you
> betting you can make that less work than a bunch of compiler engineers
> can? Note, this actually isn't a bad bet with GC, but it's not a good
> one either.
But I simply know the business logic and the logic of my program. And often it
is simply a series of:
- Create object
- Use it a little
- Dispose object
And C# has even create something just for this:
using (SomeClass someObject = new SomeClass())
{
// Do something with the object ...
}
(It is simply using creating some kind of try finally with a Dispose Call
inside the finally if I am right.)
So there is simply no need for any complex logic. Of course a Garbage collector
can do a lot of nice stuff up to some graphs stuff to detect some Objects that
simply reference each other but no thread can ever reach them.
And what is also important: The Dispose is not freeing memory. But the Objects
are simply ready for destruction and the GC can free the memory in a simply run
with no big effort.
> That sounds exactly like reference counting and it suffers from all
> the well known problems (like retain cycles). The point here is that
> you don't *want* the developer to have control, the developer (myself
> included) is really really bad at doing this, and introduces a *lot*
> of bugs in the process.
> The option for it of course will keep everyone happy, but that doesn't
> mean it should be encouraged ;)
No, It does not really mean reference counting. Of course it is not good to
dispose an object when there is still a reference on it. (In c# this reference
is still valid but simply points to a disposed object so that all internel
references are "cleared".)
- One big advantage is, that you simply resolve "paths" of object references
with results in less work for the garbage collector.
- another big advantage can be the quicker memory deallocation. The world is
not just "managed code". I am quite sure, that the Developer on a Mac also has
a lot of existing modules he wants to use that allocates memory and so. And if
you wait till dispose() is called by the GC, you could have waisted memory in
that time. (Which the GC couldn't see, because the memory involved was not
managed by the GC)
Maybe it helps a little to clarify:
- Dispose is not deallocating memory! It is just doing the logic required to
make the object ready for destruction. One important part for that is simply
setting references to null.
- Finalize is what is done directly before the destruction (So far that part
was never important for me in all my developing practice)
So the management of the memory is done by the GC, but we simply help the GC
(and keep care of other resources that are not managed)
Hope I was able to clarify this a little. The link to CodeProject also gives
such an overview but I know that it is not of any interest for an objective-c
developer because it only handles managed code / Microsoft .Net Framework. (And
I am really sorry - maybe I simply should have waited till I am much deeper
inside all this Objective-C / Cocoa stuff. Reading all the discussion about the
GC pros and cons simply made me write something, too.)
With kind regards,
Konrad
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
