finalizer vs IDisposable

[jim]

Why was a destructor (finalizer) included in the syntax
of C# if implementing IDisposable is the sure way to
release resources held by a class? If you were doing a
language from scratch would you include finalization
syntax or force users to to explicit cleanup using
IDisposable?

 

[Jay B. Harlow [MVP - Outlook]]

Jim,

Why was a destructor (finalizer) included in the syntax
of C# if implementing IDisposable is the sure way to
release resources held by a class?

Finalizer is guaranteed (*) to be called by the GC. The object designer is
taking it on faith that the developer using his object will call
IDisposable.

Normally the developer will use IDisposable in a more timely manner than
waiting for the GC to get around to it.

Which is why when you design a Class you need to implement both (when either
is required). For details see:

Implementing Finalize and Dispose to Clean Up Unmanaged Resources in the
Design Guidelines for Class Library Developers:
http://msdn.microsoft.com/library/d.../en-us/cpgenref/html/cpconfinalizedispose.asp

(*) I believe the Finalizer is not guaranteed to be called if you terminate
the program itself, and a couple of other very rare cases.

If you were doing a
language from scratch would you include finalization
syntax or force users to to explicit cleanup using
IDisposable?

For a language targeting .NET (or Java) I would support both.

Hope this helps
Jay

 

[Nicholas Paldino [.NET/C# MVP]]

Jim,

Destructors were not included in the syntax of C#. While it looks
similar to the syntax of a destructor in C++, it is a finalizer, and has a
completely different effect. IDisposable was included to provide
deterministic finalization semantics to the language (although it is not
automatic, as in C++).

When the designers were creating the language from scratch, they didn't
think that they were including destructor syntax, but rather, finalization
syntax. The same applies for Java, the syntax is the same as C++, but the
effect is completely different.

Hope this helps.

 

[Cowboy \(Gregory A Beamer\)]

There are items that can wait for GC, and items that cannot. Using a mix of
finalize and Dispose, you can get the best of both worlds. In general, you
don't want to dink with the Finalize, but there are instances where it is
needed. I have not seen one in my work thus far, but I have seen examples
that make sense.

--
Gregory A. Beamer
MPV; MCP: +I, SE, SD, DBA

**********************************************************************
Think outside the box!
**********************************************************************

 

[Tom Shelton]

Why was a destructor (finalizer) included in the syntax
of C# if implementing IDisposable is the sure way to
release resources held by a class? If you were doing a
language from scratch would you include finalization
syntax or force users to to explicit cleanup using
IDisposable?

GC is non-derministic - because of this, there is no way to dertermine
when your objects will be collected. If you are holding on to
unmangaged resources (and in some special cases managed resources) this
can be a bad thing. So having finalizers alone is not enough to ensure
proper release of resources. By using IDisposable, you give your self
control over exactly when resources are released. This is a good thing,
because it brings a degree of determinism and also lets you avoid the
performance penalty incured by having a finalizer (it takes two passes
of the GC to release objects with finalizers).

Basically, the common implementation (especially when dealing with
unmanaged resources) is to have the finalizer and implemnt IDisposable.
This makes sure that your resources will be released eventually in
case a client inadvertantly forgets to call dispose. Of course,
normally in the dispose method you will see a call to
System.GC.SupressFinalize(this) - to avoid the preformance penalty that
would be incured when the object was GC'd...

HTH,
Tom Shelton

 

[jim]

thanks for the responses guys. very helpful.