Dispose pattern

[Samuel R. Neff]

I thought an object was put on the finalizer queue when it's detected
to no longer be referenced (directly or indirectly). I don't
understand how it would work that objects are put on the finalizer
queue upon instantiation.

Sam

------------------------------------------------------------
We're hiring! B-Line Medical is seeking .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.

 

[Jon Skeet [C# MVP]]

I thought an object was put on the finalizer queue when it's detected
to no longer be referenced (directly or indirectly). I don't
understand how it would work that objects are put on the finalizer
queue upon instantiation.

Yes, you're right - my mistake in terms of terminology. The principle
was apparently right though - from

http://www.bluebytesoftware.com/blog/PermaLink.aspx?guid=88e62cdf-5919-4ac7-bc33-20c06ae539ae

<quote>
Annotation (Herb Sutter): You really don't want to write a finalizer
if you can help it. Besides problems already noted earlier in this
chapter, writing a finalizer on a type makes that type more expensive
to use even if the finalizer is never called. For example, allocating
a finalizable object is more expensive because it must also be put on
a list of finalizable objects. This cost can't be avoided, even if the
object immediately suppresses finalization during its construction (as
when creating a managed object semantically on the stack in C++).
</quote>

It's this "list of finalizable objects" which I was erroneously
calling the finalizer queue. Apologies for the confusion. I wish I had
more details about it, but it's fairly hard to find comprehensive
documentation on this kind of thing

(The link is to a fantastic article about this whole topic though.
Well worth a read.)

Jon

 

[Samuel R. Neff]

One thing that's really important to me about the Dispose pattern is
that there is a defined standard about how IDisposable should be
implemented. When implemented that way, it works very well and
perhaps there is some perceived and minor performance hit but in
practice all of the MS classes that use IDisposable are implemented
per the standard so if you're saving yourself some small amount of
time by skipping the finalizer, it'll only help in your custom
classes.

The advantage of sticking to a standard is that all projects will be
coded the same way and you can move from project to project or company
to company and can expect things to be coded properly. If they're
not, there is a defined standard to fall back on which defines the
correct way.

When we interview candidates we always ask about the GC and
IDisposable and I'm pretty sure we've had less than 5 candidates out
of hundreds that can actually explain what IDisposable is for much
less how to correctly implement it in a custom class.

Sam

 

[Jon Skeet [C# MVP]]

One thing that's really important to me about the Dispose pattern is
that there is a defined standard about how IDisposable should be
implemented. When implemented that way, it works very well and
perhaps there is some perceived and minor performance hit but in
practice all of the MS classes that use IDisposable are implemented
per the standard so if you're saving yourself some small amount of
time by skipping the finalizer, it'll only help in your custom
classes.

The defined standard about how to implement IDisposable *avoids* a
finalizer though, unless you've got unmanaged resources - that's what
the link I posted before recommends.

The advantage of sticking to a standard is that all projects will be
coded the same way and you can move from project to project or company
to company and can expect things to be coded properly. If they're
not, there is a defined standard to fall back on which defines the
correct way.

Yes, but it doesn't include a finalizer unless you've got unmanaged
resources or expect a derived class to

When we interview candidates we always ask about the GC and
IDisposable and I'm pretty sure we've had less than 5 candidates out
of hundreds that can actually explain what IDisposable is for much
less how to correctly implement it in a custom class.

Yes, I've heard some pretty odd things in that respect...

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

It's this "list of finalizable objects" which I was erroneously
calling the finalizer queue. Apologies for the confusion. I wish I had
more details about it, but it's fairly hard to find comprehensive
documentation on this kind of thing

The list of finalizable objects is actually called the "finalization
queue". This is a bit confusing, as it sounds as if it contained objects
that are up for finalization.

The list of object that is up for finalization is called the "freachable
queue".

http://msdn.microsoft.com/msdnmag/issues/1100/gci/

 

[Jon Skeet [C# MVP]]

The list of finalizable objects is actually called the "finalization
queue". This is a bit confusing, as it sounds as if it contained objects
that are up for finalization.

So I'd accidentally got the right terminology to start with. Cool
Maybe I'd seen the right way somewhere before and remembered it
subconsciously...

Shame so many articles use the more intuitive but incorrect terminology
then