Dispose Again!

  • Thread starter Thread starter Guest
  • Start date Start date
Cor,
There is no need to dispose any object of system.data.
Where do you get that in the link you gave???

If anything the link you gave says you need to call Dispose (or Close).

Your statement may be (partially) true for the System.Data namespace itself,
however it is not even close to true for (most of) System.Data.Odbc,
System.Data.OleDb, System.Data.SqlClient, and System.Data.OracleClient! As
they all contain classes that deal with "external" (aka unmanaged) resource.

Hope this helps
Jay
 
Dennis,
I have implemented the practice of "If it's got a
dispose method, then call it when I'm thru with it and if it doesn't have
a
dispose method, don't worry about it!"
Without "knowing" for certain that IMHO is the "best" practice.

The "better safe then sorry" pattern. :-)

Hope this helps
Jay
 
If I understand Dispose() correctly, it simply forces the .NET framework
to mark an object for Garbage Collection.

Not necessarially. An object is marked for collection when nothing is
pointing at it any longer.
As I look at the "Windows Forms Designer generated" Dispose() method of a
Form, it is appears that the Form itself performs Dispose() on all the
Form's components, which if I'm not mistaken, would include labels, etc.

Correct, but since the designer has no idea what kind of controls you'll be
putting on your form, it takes the better safe than sorry approach and
disposes your controls (even if they don't need to be disposed).
As I understand it, Dispose() does not force a Garbage Collection, so that
should not be an issue.
Correct.

Is there any real benefit to *not* calling Dispose() on objects that
expose it once you know that they are no longer needed (such as a
SqlCommand), or is there a complex matrix of rules for when and when not
to use Dispose() that should be referenced every time you create a new
object?

Calling Dispose on a label wouldn't *hurt* anything, but it would cause your
application to perform additional tasks that may not be needed. So, it
could conceivably slow an application down to be calling Dispose on
everything, rather than just the things that really need it.
 
Jay,

What has it for sense to dispose every individual part of a class when the
base class does the dispose?
Your statement may be (partially) true for the System.Data namespace
itself, however it is not even close to true for (most of)
System.Data.Odbc, System.Data.OleDb, System.Data.SqlClient, and
System.Data.OracleClient! As they all contain classes that deal with
"external" (aka unmanaged) resource.

Do you mean that I understand this page wrong?

http://msdn.microsoft.com/library/d...mcomponentmodelcomponentclasshierarchy.aspCor
 
This is the thrid or fourth different question I've posed on this newsgroup
about dispose and really enjoy the "confusion". If Microsoft is listening,
then they should step up and "in plan English" explain when to dispose and
when not to. They give hints and sometimes even state that something needs
to be disposed in their MSDN help but I sure wish they'd put this like in the
header of the help sheets such as "Dispose needed - Yes/No"
 
Scott M. said:
Not necessarially. An object is marked for collection when nothing is
pointing at it any longer.

What does Dispose() do exactly?
Correct, but since the designer has no idea what kind of controls you'll
be putting on your form, it takes the better safe than sorry approach and
disposes your controls (even if they don't need to be disposed).

Are you advocating getting rid of the Windows Forms Designer generated code
as unnecessary? Or are you saying that "better safe than sorry" only
applies to Designer generated code and not to code created by a programmer?
Calling Dispose on a label wouldn't *hurt* anything, but it would cause
your application to perform additional tasks that may not be needed. So,
it could conceivably slow an application down to be calling Dispose on
everything, rather than just the things that really need it.

So, logically:

1. Calling Dispose() on a label wouldn't *hurt* anything;
2. Calling Dispose() on a label would cause your application to perform
additional tasks that *may* not be needed
3. Calling Dispose() on a label *could conceivably* slow down an
application
4. Therefore, *don't* call Dispose() on SqlCommands

Does that about sum up the train of thought here?

If the Matrix of objects on which you should call Dispose() versus those on
which you should not call Dispose() is as convoluted as this logic, how do
programmers get anything done without spending cross-referencing which
objects should and should not be Disposed of. How in the world do you write
even the simplest of programs without spending hours worrying about this
low-level garbage?
 
I think your link sums it all up Perfectly:

"Page Cannot Be Found
We apologize for the inconvenience, but the page you are seeking cannot be
found in this location."
 
OK. Take three scenarios.

(1) Dispose is present in a class but does nothing.
(2) Dispose is present in a class and cleans up unmanaged resources.
(3) Dispose is present in a class and does some clean up logic but its all
managed code.

In the case of (1), it won't hurt to call it because the JIT will optimize
the call away. So it costs you nothing to make the call. I vote make the
call to Dispose.

In the case of (2) the class will also override the finalize method. This
logic will be called either by calling Dispose or by the finalize thread. So
calling it or not calling it doesn't hurt you either way, the call will be
made. But waiting for the finalize method to be called is a bad idea because
you are hanging onto the unmanaged resources until the finalize thread is
run and there is no guarantee when that will be, and in the case of a file
handle or database connection that can be a real bad thing. Plus if you wait
till the finalize method is called, the object goes through an additional
garbage collection. I vote make the call to Dispose.

In the case of (3) the class developer put code into the Dispose method so
people using an instance of the class will call it when they are done with
the instance of the class. This may cost you some performance but you are
heeding the advice of the class developer. Example might be, the class
registers as a listener for a global event, and calling Dispose unregisters
itself as a listener, if you don't call Dispose setting the object to
Nothing will leave it alive because a reference of the object is still
registered to the global event. This can and will be seen as a memory leak
as long as your application runs. As for the performance hit, if your
application is having performance problems I'll guarantee you the solution
won't be go through your code and remove all the calls to Dispose. I vote
make the call to Dispose.

So there you have my logic. (1) and (2) to me are a no brainer, make the
call to Dispose. As for (3) listen to the class developer, don't worry about
performance until performance problems arise, and by then you will be
profiling your application and chances are the problem won't be the calls to
Dispose.

Plus there is an additional thing you must think about and thats just
because the current version of the object's Dispose method does nothing or
the current version of the class doesn't use unmanaged resources, that
doesn't mean future versions of it will not. Making the decision of not
calling Dispose now might hurt you in the future when new versions of the
class is installed into production.
 
Cor,
What has it for sense to dispose every individual part of a class when the
base class does the dispose?
I'm sorry but above statement does not make sense, can you explain what you
mean?
Obviously you are! as that lists a list of components. It says nothing about
needing or not needing to call Dispose, you need to look at each class
individually to decide if Dispose is needed or not.

Honestly Cor, I have seriously wonder if you are smoking something or
popping some pills here as you are making zero sense!

Hope this helps
Jay
 
Dennis,
I'm half thinking an attribute would be nice, that the compiler could check
& issue a warning if you did not call dispose. Of course this could get
interesting as you try to navigate the call graph & ensure that the correct
spot calls dispose on the variable...

Of course the problem then becomes when class designers forget to add the
attribute to their class.

You could always submit a suggestion at:

http://lab.msdn.microsoft.com/vs2005/

Seeing as Beta 2 is "just around the corner", it may be too late for VS.NET
2005 (.NET 2.0) however it might be considered in the next version (3.0 or
later)...

Hope this helps
Jay
 
So again, we get back to someone's recommendations somewhere; presumably the
class developer's recommendation. So now the question becomes where is the
chart that breaks down every single .NET class into your cool little
categories, 1, 2, and 3?

Now on top of having to reference these mythical recommendations I first
have to do a Google on the class I'm using. Then I have to do a comparison
of the yea's versus the nay's that might come up; on this board, for
instance, I've seen over half a dozen opinions. Then I have to decide
whether there is overwhelming support for calling Dispose() on a particular
class or not; and if it falls somewhere in the middle, 50/50, I have to
basically just guess at it.

Q: Are you supposed to use Dispose() on a SqlCommand?
A: Don't use Dispose() on a Label

This is fascinating, but I think I'll stick with Disposing of everything
that offers me the opportunity. After all, I've got code to write and not a
lot of time to spend trying to categorize the entire .NET framework into
your handy little categories. If I hit performance problems, I can look at
the Dispose() calls as a possible source and remove them later; but for now
I'm trying to develop rapidly, not sort through - and categorize - all of
the .NET framework's Dispose() methods.
 
I don't think you read my message in the manner I was intending. I never
said you should break down and catagorize every .NET class you ever use. I
was stating my reasons why you should call Dispose on every class that
implements Dispose.

And if you have performance problems, I suggest using a profiler first
because your problems won't be because of the Dispose method.
 
Michael and Dennis,
So again, we get back to someone's recommendations somewhere; presumably
the class developer's recommendation.
Unfortunately that may be the "Best" you are going to get. I normally read
the documentation on the class to see if Dispose is "required". If I'm using
a lot of the objects of a Disposable type & I'm in doubt I normally call
Dispose. If I have only one or two instances & I'm in doubt I may not call
it, as waiting for Finalize may not be that big a deal. Of course if
profiling (too many objects waiting to be finalized by the GC) or other
system problems (connection pool running dry) indicates that I should be
calling Dispose then I will...

To see "exactly" what Dispose does, at least what its intent is see:

http://msdn.microsoft.com/library/d.../en-us/cpgenref/html/cpconFinalizeDispose.asp

Dispose & Finalize are used together to provide an explicit (Dispose) and
implicit (Finalize) method of releasing unmanaged resources an object may be
directly using. If the class has unmanaged resources then Finalize will
clean them up. Dispose allows you to do this clean up early & suppress the
finalization. By suppressing the finalization you enable the garbage
collector to run more efficiently. You can use tools such as the CLR
profiler & PerfMon to find out how many objects are


As JD has suggested Dispose can do one of three things:

1) nothing
2) cleans up unmanaged resources
3) cleans up managed resources

I use #3 in my classes when I have a class that contains (Has a) #2 class.
#1 classes are common in the DataSet object model & classes that inherit
from System.ComponentModel.Component. NOTE: a number of classes that inherit
from Component are #2 or #3 classes! For example most controls
(System.Windows.Forms.Control) are #2 classes as they contain a Win32 window
handle.

Now IMHO there are 3 schools of thought on calling Dispose:

1) Never call Dispose, instead let the Finalizer take care of unmanaged
resources. This is probably the worst & sloppiest attitude you can take on
calling Dispose. Profiling & various exceptions will indicate problems when
using this method.

2) Always call Dispose, the "better safe then sorry" pattern.

3) "Appropriately" call Dispose. Unfortunately this is the hardest one to
achieve, as you need to learn from experience, others, or profiling &
various exceptions... It is the one I strife for...


Info on the CLR Profiler:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenethowto13.asp

http://msdn.microsoft.com/library/d...y/en-us/dndotnet/html/highperfmanagedapps.asp

FWIW: VB.NET 2005 (.net 2.0 aka Whidbey, due out later in 2005) will include
a Using statement that will simplify calling Dispose for you.

http://msdn2.microsoft.com/library/htd05whh.aspx

Using thePen As New Pen(...)
gr.DrawLine(thePen, ...)
gr.DrawLine(thePen, ...)
gr.DrawLine(thePen, ...)
gr.DrawLine(thePen, ...)
End Using


Hope this helps
Jay
 
Michael,

The link works perfectly only the message connected my name on it.
You could have seen that I corrected that almost an hour because you wrote
your message.

Cor
 
Scott,

I have read this as well, however mostly is it written that every class that
has a dispose SHOULD be dispose. This means because that every class that
for every class that derives from components should be composed.

That means every label, every checkbox, etc etc. do you do that?

Cor
 
Scott,

My text is unreadable sorry.

I have read what you wrote about "SHOULD" as wel often, mostly is than
written that for every class that has a dispose the dispose method SHOULD
be used. This would mean that every label, checkbox, etc etc. should be
disposed, because they all derive from components (see the link I showed in
this thread). Do you do that?

Cor
 
JD,

This means. that what you write should be done, this is about class that
derives from this list and those classes themselves.

http://msdn.microsoft.com/library/d...stemcomponentmodelcomponentclasshierarchy.asp

In this are label, textbox, etc.

Calling a dispose individualy explicitly (in classes where Idispose is
implemented) optimezes the process of garbage collection. However the GC is
running in the idle time of a program. For me it is foolish to use the
running proces time from a program to optimize processes which run in idle
time like the GC.

However that clear is the documentation not, for me the documentation about
dispose is the most inconsequent on MSDN. Especially because that it
sometimes it even directly related with finalize methods, however that is in
my opinion the most important reason why managed code is called managed
code.

So when the managed code is not able to do finalize, than there is no need
for managed code and than it could be remove in a way as Dennis and Michael
write it.

However that is not the way I am thinking about it as you saw.

Just my thought

Cor
 
Jay,
Honestly Cor, I have seriously wonder if you are smoking something or
popping some pills here as you are making zero sense!

Please don't stalk me, this you have now written more times about me.

I always try to avoid people who are arguing on this low level. Only because
they think that there freedom of speech has given them freedom to tell
things about other people in other cultures, just because they have seen it
by instance on Fox television.

You are for me an example for those Americans who create that bad view of
the Americans outside the USA and are unlucky enough indirect responsible
for the results of that.

You have lost all your credits from me.

Cor
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Back
Top