Re: GC pros and cons
Re: GC pros and cons
- Subject: Re: GC pros and cons
- From: "Stephen J. Butler" <email@hidden>
- Date: Wed, 24 Jun 2009 20:02:45 -0500
On Wed, Jun 24, 2009 at 7:40 PM, Jeff Laing<email@hidden> wrote:
> http://www.simple-talk.com/dotnet/.net-framework/understanding-garbage-collection-in-.net/
>
> (Yes, I do .NET as well as Cocoa)
>
> No real surprises there, except for the closing paragraphs which can be paraphrased down to "If you need memory to be collected efficiently, you should implement IDisposable and call Dispose() explicitly when you are done with your objects". Which gives a net gain of zero, since you need to call Dispose() exactly where you used to call Release(). To make the automatic model (GC) work efficiently every time, you need to replicate the manual (retain/release) model, all the while presumably telling yourself that "this is so much better than what I had".
Well, no, that's not a good summary of the last couple paragraphs. IF
YOU HAVE A FINALIZER, then you should probably be using the
IDisposable interface. Objects with finalizer methods essentially need
two passes, since actions in the finalizer can cause objects that
would have been collected to end up in a root again. So you pass once
to finalize, and again to make sure the object is still collectable.
But the reason people need finalizers is usually because they're
holding open some external resource that needs special closing: a
connection to a server, a file, an OS handle, etc. That's where
IDisposable comes in. People can then use the using() construct, which
closes the external resource as soon as possible. But you write a
finalizer just in case programmers aren't careful and forget to use
using() or call Dispose() manually. The GC.SuppressFinalize() is just
a hint to tell the runtime you've handled the external resource and it
can collect in one pass.
None of this is anything like retain/release or reference counting.
And is easier, IMHO. Even when you screw up and forget to call
release, your object is still eventually collected and its external
resource closed.
_______________________________________________
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