Ok, I'm trying to dispose of every object that I create that has a dispose
method based on advice from this newsgroup. However, I'm not sure how to
dispose of the following object that was created inside a method call.
dim myvar as new object1
object1.dosomethingmethod(new object2)
Note that object 2 has a dispose method but how do I dispose of it unless I
do the following:
dim myvar as new object1
dim mydisposableobject as new object 2
object1.dosomethingmethod(mydisposableobject )
myotherobject.Dispose
--
Dennis in Houston
Nov 21 '05
156  5384 
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?
Do you mean that I understand this page wrong?
http://msdn.microsoft.com/library/de...erarchy.aspCor
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
"Cor Ligthert" <no************@planet.nl> wrote in message
news:uF**************@tk2msftngp13.phx.gbl... 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/de...erarchy.aspCor
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
"Dennis" <De****@discussions.microsoft.com> wrote in message
news:D0**********************************@microsof t.com... 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." wrote:
> 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.
>
> "Cor Ligthert" <no************@planet.nl> wrote in message
> news:ul*************@TK2MSFTNGP12.phx.gbl...
>> Dennis,
>>
>> When you inherit from Components than there is already Idispose
>> implemented in the base class. (By instance all classes in Sytem.Data
>> and
>> System.Windows.Forms.Control inherit from Components) You just have
>> to
>> do nothing because it is done by the base class when that class goes
>> out
>> of scope. Therefore I inherit from components when I make a class from
>> which I have slightly the idea that it has unmanaged resources in it.
>>
>> http://search.microsoft.com/search/r...&c=0&s=1&swc=0
>>
>> IComponent implements IDisposable for when you are searching that.
>>
>> I hope this helps,
>>
>> Cor
>>
>
>
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.
"JD" <an*******@discussions.microsoft.com> wrote in message
news:ab********************@comcast.com... 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.
"Michael C#" <xy*@abcdef.com> wrote in message
news:ZW*****************@fe10.lga... "Scott M." <s-***@nospam.nospam> wrote in message
news:e%****************@TK2MSFTNGP14.phx.gbl... >> 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.
What does Dispose() do exactly?
>
>>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).
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? >> 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.
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 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 C#" <xy*@abcdef.com> wrote in message
news:nb***************@fe09.lga... 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.
"JD" <an*******@discussions.microsoft.com> wrote in message
news:ab********************@comcast.com... 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.
"Michael C#" <xy*@abcdef.com> wrote in message
news:ZW*****************@fe10.lga... "Scott M." <s-***@nospam.nospam> wrote in message
news:e%****************@TK2MSFTNGP14.phx.gbl...
>> 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.
What does Dispose() do exactly?
>
>>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).
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?
>> 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.
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?
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/de...izeDispose.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/de...nethowto13.asp
http://msdn.microsoft.com/library/de...anagedapps.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 C#" <xy*@abcdef.com> wrote in message
news:nb***************@fe09.lga... 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.
"JD" <an*******@discussions.microsoft.com> wrote in message
news:ab********************@comcast.com... 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.
"Michael C#" <xy*@abcdef.com> wrote in message
news:ZW*****************@fe10.lga... "Scott M." <s-***@nospam.nospam> wrote in message
news:e%****************@TK2MSFTNGP14.phx.gbl...
>> 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.
What does Dispose() do exactly?
>
>>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).
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?
>> 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.
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?
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
Michael,
That is completly what I try to tell as well.
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/de...shierarchy.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
> This means. that what you write should be done, this is about class that derives from this list and those classes themselves.
This means that what you write should be done for all classes that by
instance derive from components.
This..........................
Scott,
Maybe it is good to remind that I wrote this in my starting answer. Therefore I inherit from components when I make a class from which I have
slightly the idea that it has unmanaged resources in it.
This means for me every class which has interop or an Api in it.
(In fact I just open a component in the items and use that template).
Cor
> 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.
The GC does not run in idle time. It runs when there is a need to collect
memory. If a program is doing nothing or is idle the GC will not run and
will not collect any objects. The GC runs more when the progam is actually
busy!
> 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...
I agree with these three suggestions. I myself use 3, but when I see people
struggling with Dispose I suggest 2. I strongly agree about number 1.
Cor,
I'm sincerely sorry about the off color joke. It was meant purely as a joke,
and nothing about your culture.
However my question about what you are talking about in this thread still
stands!
There are times when what you state makes no sense (such as your answers in
this thread). There are times when your answers make a lot of sense!
I'm certain it is not just me, as I've noticed others have questioned a
number of your answers also! You have lost all your credits from me.
Unfortunately I cannot say the same about you! As you do provide valuable
information in the newsgroups. Its just sometimes (such as this thread) it
is hard to make heads or tails out of what you are saying. When I or others
ask for clarification of what you were thinking, you sometimes get overly
defensive or a little less coherent (such as posting the list of classes).
Just a thought
Jay
"Cor Ligthert" <no************@planet.nl> wrote in message
news:ej**************@TK2MSFTNGP15.phx.gbl... 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
Is it possible, that in the future, the Dispose() method on some Framework
objects might include more clean-up in their Dispose() method than they do
now? For instance, Angel Saenz-Badillos from MS posted a message to Cor
previously in the ADO.NET newsgroup: http://groups-beta.google.com/group/...e5f2f511b2f7bd
He basically says that they were going to put more functionality in the
SqlCommand Dispose() method which would have made it necessary to call
Dispose() on your SqlCommand's in .NET 2.0. They ended up leaving it out,
but the fact they toyed with the idea leads me to believe there might be
changes down the road.
With that in mind, if they *had* implemented this particular change, or
changes in other class's Dispose() methods, does that mean all those who
pick and choose when and where to call Dispose() might spend fair amounts of
time re-learning a new set of rules and changing their programming patterns?
I still think #2 is the best fit for my needs. After all, if they change
the actual functionality of the Dispose() method for a particular class I
use in the future, I won't end up wasting a bunch of time trying to "fix"
all my code to match the newest Developer Recommendations.
Of the things lacking in VB, the C#-like "using" keyword is wayyyy at the
top of my list.
"JD" <an*******@discussions.microsoft.com> wrote in message
news:DL********************@comcast.com... 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...
I agree with these three suggestions. I myself use 3, but when I see
people
struggling with Dispose I suggest 2. I strongly agree about number 1.
Yeah Cor, I just visited that new link and I still don't see how it relates?
"Cor Ligthert" <no************@planet.nl> wrote in message
news:uB*************@TK2MSFTNGP10.phx.gbl... 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
Yes, but then you went on to say:
"There is no need to dispose any object of system.data."
And that is what I responded to because that is untrue.
"Cor Ligthert" <no************@planet.nl> wrote in message
news:eT*************@TK2MSFTNGP14.phx.gbl... Scott,
Maybe it is good to remind that I wrote this in my starting answer.
Therefore I inherit from components when I make a class from which I have
slightly the idea that it has unmanaged resources in it.
This means for me every class which has interop or an Api in it.
(In fact I just open a component in the items and use that template).
Cor
Dispose is nothing more than a method that the class creator adds when they
need a place to write code that will release the unmanaged resources that
the class uses. It is up to the class user to call this method.
That's it...that's what dispose is.
"Michael C#" <xy*@abcdef.com> wrote in message
news:ZW*****************@fe10.lga... "Scott M." <s-***@nospam.nospam> wrote in message
news:e%****************@TK2MSFTNGP14.phx.gbl... 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.
What does Dispose() do exactly?
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).
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?
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.
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?
"Scott M." <s-***@nospam.nospam> wrote in message
news:uD****************@TK2MSFTNGP12.phx.gbl... Dispose is nothing more than a method that the class creator adds when
they need a place to write code that will release the unmanaged resources
that the class uses. It is up to the class user to call this method.
That's it...that's what dispose is.
That's great. Nice quick, easy definition. I'm sure it sheds new light on
the problem of when to call Dispose() and when to ignore it completely.
I was under the mistaken impression that the GC could call Dispose(), as
well as the "class user".
I think the one thing we can all agree upon is that nothing is "automatic".
It comes down to this for me:
1. I know that the class needs it's dispose method to be called and I call
it (OleDbConnection, for example).
2. I know the class has a dispose, but it is a "relic" of inheritance and
doesn't need to be called, so I don't call it (label, for example).
3. There is no dispose method, so problem solved.
4. I'm not sure so:
4a. I call it anyway to be safe.
4b. I research the class to see if it is indeed needed or is a relic.
"Michael C#" <xy*@abcdef.com> wrote in message
news:VV*****************@fe08.lga... "Scott M." <s-***@nospam.nospam> wrote in message
news:uD****************@TK2MSFTNGP12.phx.gbl... Dispose is nothing more than a method that the class creator adds when
they need a place to write code that will release the unmanaged resources
that the class uses. It is up to the class user to call this method.
That's it...that's what dispose is.
That's great. Nice quick, easy definition. I'm sure it sheds new light
on the problem of when to call Dispose() and when to ignore it completely.
I was under the mistaken impression that the GC could call Dispose(), as
well as the "class user".
No Cor, that is not what I'm referring to. What I've read about the
DataReader, Connection and DataAdapter classes is that they DO use unmanaged
resources and SHOULD be disposed. I'm not talking about labels here. You
said there is no reason to call dispose on any of the data classes. I must
disagree. I believe that to be incorrect.
"Cor Ligthert" <no************@planet.nl> wrote in message
news:O8****************@tk2msftngp13.phx.gbl... 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
Michael, With that in mind, if they *had* implemented this particular change, or
changes in other class's Dispose() methods, does that mean all those who
pick and choose when and where to call Dispose() might spend fair amounts
of time re-learning a new set of rules
IMHO the "set of rules" remains constant, by "set of rules" I mean JD's
three rules which are rather simple. IMHO my list of 3 are more mantalities
for managing JD's three rules...
What would change is the list classes that now either "require" or not
"require" dispose changes. I would expect classes that went from not
requiring Dispose to now requiring Dispose to directly or indirectly to show
up under the "Profiling & various exceptions" clause of my 3 rules...
Of the things lacking in VB, the C#-like "using" keyword is wayyyy at the
top of my list.
As I've stated before, VB.NET 2005 will get the same "using" statement that
C# has to help manage IDisposable classes...
Hope this helps
Jay
"Michael C#" <xy*@abcdef.com> wrote in message
news:Hu***************@fe08.lga... Is it possible, that in the future, the Dispose() method on some Framework
objects might include more clean-up in their Dispose() method than they do
now? For instance, Angel Saenz-Badillos from MS posted a message to Cor
previously in the ADO.NET newsgroup:
http://groups-beta.google.com/group/...e5f2f511b2f7bd
He basically says that they were going to put more functionality in the
SqlCommand Dispose() method which would have made it necessary to call
Dispose() on your SqlCommand's in .NET 2.0. They ended up leaving it out,
but the fact they toyed with the idea leads me to believe there might be
changes down the road.
With that in mind, if they *had* implemented this particular change, or
changes in other class's Dispose() methods, does that mean all those who
pick and choose when and where to call Dispose() might spend fair amounts
of time re-learning a new set of rules and changing their programming
patterns? I still think #2 is the best fit for my needs. After all, if
they change the actual functionality of the Dispose() method for a
particular class I use in the future, I won't end up wasting a bunch of
time trying to "fix" all my code to match the newest Developer
Recommendations.
Of the things lacking in VB, the C#-like "using" keyword is wayyyy at the
top of my list.
"JD" <an*******@discussions.microsoft.com> wrote in message
news:DL********************@comcast.com... 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...
I agree with these three suggestions. I myself use 3, but when I see
people
struggling with Dispose I suggest 2. I strongly agree about number 1.
Michael, I was under the mistaken impression that the GC could call Dispose(), as
well as the "class user".
The GC will never directly call Dispose! The GC will only directly call
Finalize! Finalize may or may not call Dispose. Normally Dispose & Finalize
will call a common routine.
http://msdn.microsoft.com/library/de...izeDispose.asp
Hope this helps
Jay
"Michael C#" <xy*@abcdef.com> wrote in message
news:VV*****************@fe08.lga... "Scott M." <s-***@nospam.nospam> wrote in message
news:uD****************@TK2MSFTNGP12.phx.gbl... Dispose is nothing more than a method that the class creator adds when
they need a place to write code that will release the unmanaged resources
that the class uses. It is up to the class user to call this method.
That's it...that's what dispose is.
That's great. Nice quick, easy definition. I'm sure it sheds new light
on the problem of when to call Dispose() and when to ignore it completely.
I was under the mistaken impression that the GC could call Dispose(), as
well as the "class user".
On 2005-03-20, Jay B. Harlow [MVP - Outlook] <Ja************@msn.com> wrote: Michael and Dennis, So again, we get back to someone's recommendations somewhere; presumably
the class developer's recommendation.
As JD has suggested Dispose can do one of three things:
1) nothing
2) cleans up unmanaged resources
3) cleans up managed resources
True, but I think this hides what is really the cause of most of the
confusion around Dispose, which is that Dispose can do different things
at different times.
Most commonly, there's an awful lot of objects that don't need to be
disposed at runtime but have a visual representation of themselves in
Visual Studio that *does* need to be disposed.
Web controls are the perfect example of that. At design time, they need
to be disposed otherwise you'll squander windows resources. But at
runtime, there's nothing to dispose. Also, if you think about it,
there's no reasonable time for user code to dispose a web control at
runtime (Page.Unload maybe?).
This may have been what Cor was getting at earlier. All the standard
System.Data objects: Connections, DataAdapters, DataSets, DataReaders,
none of them need to be disposed at runtime. It doesn't hurt anything
to call Dispose on them, it just does nothing useful (you *do* have to
close them, and Dispose will call Close for you if necessary, but that's
something else). But they all have visual representations that need to
be disposed at design time, so they need to implement IDisposable.
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...
#3 is what most of us probably do, and it's the best solution for a bad
problem IMHO.
But in the land of inheritance and interfaces, there's the possibility
here of a time bomb. I may know I don't have to Dispose a
SqlDataAdapter or DataSet, but what if my DAL hands me an IDataAdapter
from some weird implementation that needs disposing and or a DataSet
object that *might be* a class that inherits DataSet, and needs to
de-allocate precious resources in Dispose? Experience and profiling
doesn't help here, since the type of object I'm receiving might change
long after development has finished.
I choose to pretty much ignore those issues right now. But tossing
IDisposable on a ton of objects that don't actually need runtime
disposing was a pretty bad idea on the part of MS.
On 2005-03-21, Scott M. <s-***@nospam.nospam> wrote: No Cor, that is not what I'm referring to. What I've read about the
DataReader, Connection and DataAdapter classes is that they DO use unmanaged
resources and SHOULD be disposed. I'm not talking about labels here. You
said there is no reason to call dispose on any of the data classes. I must
disagree. I believe that to be incorrect.
This depends a bit on the type of data resources you're using. The
SqlClient stuff never needs to be disposed. OleDb objects, on the other
hand, can use a tiny bit of COM memory and so possibly they should be
Disposed (in practice I'm not so sure it matters).
Of course, there's an awful lot of other data libraries out there and it
would be hard to generalize about them.
Michael Yeah Cor, I just visited that new link and I still don't see how it
relates?
This was an answer on Jay, where he told that some classes in this list did
not derive from component.
It gives as well an answer on the question that from every method which have
a dispose the dispose should be used. All those methods and which derive
from those have a dispose just because it is in the top base class.
Cor
Scott,
"There is no need to dispose any object of system.data."
And that is what I responded to because that is untrue.
No that did I not say, because I showed you the message about connection and
any dispose method can be overridden. However, for the rest I would not know
any object in system.data that in my opinion *should* be disposed.
About the system.data object has dispose often been in the newsgroup Adonet.
I know that Angel has advised to dispose every object. However when I asked
him once why, he told more or less that it was his personal way of doing
things.
However will never tell here in a newsgroup not to dispose, I tell to use it
when it has sense, however not the sentence "When there is a dipose method
it should be used".
And that is what this thread in this message as answer on Dennis started
with.
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!"
Cor
Jay, I'm sincerely sorry about the off color joke. It was meant purely as a
joke, and nothing about your culture.
Ok accepted.
However my question about what you are talking about in this thread still
stands!
I have taken some time about the dispose, because it is something where
about in my opinion is very poorly about written and gets a different
setting when you read about it in time from old documents to newer
documents.
The old are in the style, "do dispose because it can not hurt" while the
newer get more another trend however still in my opinion not well described.
You can see that in my opinion in that "Improving .NET Application
Performance and Scalability" link you once showed me. There is a lot very
good written, however the dispose has again that "it can not hurt" trend for
me and is very brief written
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.
As they all contain classes that deal with "external" (aka unmanaged)
resource.
The big point for me is, that an unmanaged resource are in all documents
indirectly and flaw connected with managed code. Managed code is to manage
resources. There is not written something real about unmanaged resources in
that relation. For me is as long that I don't have a good document what is
an *unmanaged resource* (not a blog or whatever especially not from a
classic VB MVP) an unmanaged resource something that comes from an API,
wherefore than Idisposable should be implemented.
We arguing in this thread part of the text bellow from Dennis, where I told
to him that what he wrote was not the right method. As reaction on that you
tell in this thread part, that I don't know what I am talking about.
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!"
Therefore tell to me than what is wrong or smoked or whatever when I tell
that this is not the right but even oposite from that. I have told that when
you build your own class and it has unmanaged resource you would have to
implement Idisposable (not in those words because I gave the advice to use
components as base class where that is implemented).
There are times when what you state makes no sense (such as your answers
in this thread). There are times when your answers make a lot of sense!
I have told you more that when you *think* that when my answers as above
don't make sense to ask. However you have than in my expirience the attitude
to write than directly as if other people don't understand it. I told you
more times, that I read documentation, however when I don't trust it,
investigate it as far as I can go. Often when I wrote text like this you
give an answer starting with (shakes
head)............................................. ..
I'm certain it is not just me, as I've noticed others have questioned a
number of your answers also!
I am glad when people ask than. Than I try to clarify it, and when they
*proof* that I am wrong I have learned something again and thank them.
A sample from such a discussion where it was the oposite.
http://groups-beta.google.com/group/...d944d25a937c26
You have lost all your credits from me.
Unfortunately I cannot say the same about you! As you do provide valuable
information in the newsgroups. Its just sometimes (such as this thread) it
is hard to make heads or tails out of what you are saying. When I or
others ask for clarification of what you were thinking, you sometimes get
overly defensive or a little less coherent (such as posting the list of
classes).
A problem can be that I don't like the inline answers because they go
everytime further and further away from the starting subject. I try to keep
me on the subjects as they are top down in a thread. For some is that hard
to read. When you want that, will I change that style for you as well as I
did it for Herfried.
And maybe by coincidence however because that you wrote now "Just a
thought", when you write "I hope this helps" or just denies my answers
without any proof or reference in it, or whithout the text "in my opinion" I
probably become in a kind of what you call "overly defensive or a little
less coherent". There are only two persons who can bring me in this state in
these newsgroups. (The other one is not from this newsgroup and is now
mostly ignored by me)
As last about the list of classes. I expect that when you have written that
something is "false" and I show a list wherin that is in my opinon "true"
you understand what I mean.
I hope this clarifice something.
Cor
Scott, No Cor, that is not what I'm referring to. What I've read about the
DataReader, Connection and DataAdapter classes is that they DO use
unmanaged resources and SHOULD be disposed. I'm not talking about labels
here. You said there is no reason to call dispose on any of the data
classes. I must disagree. I believe that to be incorrect.
I have never stated that the Connection not *should* be disposed for at
least a year now. So I cannot believe that you wrote is true. In opposite of
that, I am always the one who advices in these newsgroups to use that
instead of the close for the connection.
My problem in this with the dispose is, that there is always written about
unmanaged resources. However until now I never found a good link on MSDN
what they mean with an "unmanaged resource", except some blogs from by
instance old VB classic MVP's, which are often in conflict inside the text.
Cor
Michael, This was an answer on Jay, where he told that some classes in this list did
not derive from component.
Small correction again. That was the way I understood Jay's message because
that was in my idea the main part. I readed the unmanaged resources part as
an addition. I start to understand that his meaning about the message was
more about the unmanaged resources part.
Cor
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:ur**************@tk2msftngp13.phx.gbl... IMHO the "set of rules" remains constant, by "set of rules" I mean JD's
three rules which are rather simple. IMHO my list of 3 are more
mantalities for managing JD's three rules...
What would change is the list classes that now either "require" or not
"require" dispose changes. I would expect classes that went from not
requiring Dispose to now requiring Dispose to directly or indirectly to
show up under the "Profiling & various exceptions" clause of my 3 rules...
IMHO, the "set of rules" you refer to are not rules at all; they are
patterns of usage. A rule would tell you, quite simply, "use Dispose() on
object x in situation y" or "don't use Dispose() on object x in situation
z". The "rules" I alluded to are the specific recommendations on usage
using pattern #3.
And I see we didn't even address my question, which is quite simply - and to
use your terms - when the "profiling & various exceptions" clause is
updated, how much time will be spent researching this, updating your usage
patterns, and finally updating any code you've currently completed?
It sounds to me like, to use pattern #3, you have to:
1) Perform a lot of research to determine the Developer's Recommendations,
2) Perform a lot of research to figure out the "various exceptions",
3) Potentially spend a whole lot of time researching and adjusting your code
when the Developer Recommendations change.
From what you and others have posted, this esoteric information on Dispose()
usage is gained through trial and error, from others, and of course
developer recommendations. It appears that there is no definitive "list" of
"classes that now either 'require' or not 'require' dispose", and until
someone puts a definitive list together, it doesn't make a lot of sense to
reference it as if it were a click away. (BTW - If it *is* available, then
this whole thread can be boiled down to a simple link to this definitive
"list"... and shame on whoever knows the whereabouts of this list for not
posting the link already).
At this point I don't see a significant ROI on all this time and energy
spent on trial-and-erroring my way to this sliver of mysterious knowledge,
researching Developer's Recommendations on using Dispose() for every class I
use, or posting a new message every single time I run across an object that
exposes a Dispose() method. After all, I tested the third option with the
SqlCommand object in this thread days ago, and still haven't received a
simple "YES" or "NO" concerning whether or not it should be Disposed of!
Instead I get responses concerning "Labels" and patterns of usage: ("use it
all the time", "use it none of the time", "use it correctly")!
Imagine if you had to stop development for days each and every time you ran
across a new class that exposed Dispose(), so that you could post a
newsgroup message and await a response - which might or might not be
forthcoming. Alas, it's much simpler to consistently Dispose() of my
SqlCommand, SqlConnection and other objects when I'm done with them. I
would love to see a demonstration of how all the proposed research into this
arcane trivia generates anything greater than a personal sense of
accomplishment...
Of the things lacking in VB, the C#-like "using" keyword is wayyyy at the
top of my list.
As I've stated before, VB.NET 2005 will get the same "using" statement
that C# has to help manage IDisposable classes...
Good, it's about time.
Hope this helps
Maybe not in the way you think, but thank you nonetheless.
Cor, No that did I not say, because I showed you the message about
Yes! you did say that. :-|
The very first paragraph of:
http://groups-beta.google.com/group/...3e201842e0f6b2
States "There is no need to dispose of any object of system.data", end of
paragraph.
The other two paragraphs are hard to follow, but reading it again it appears
you are saying "There is no need to dispose of *most* objects in
system.data. however Connection is one you do need to Dispose". Which is the
point I was trying to make & trying to ask you about...
Jay
"Cor Ligthert" <no************@planet.nl> wrote in message
news:OG*************@TK2MSFTNGP14.phx.gbl... Scott,
"There is no need to dispose any object of system.data."
And that is what I responded to because that is untrue.
No that did I not say, because I showed you the message about connection
and any dispose method can be overridden. However, for the rest I would
not know any object in system.data that in my opinion *should* be
disposed.
About the system.data object has dispose often been in the newsgroup
Adonet. I know that Angel has advised to dispose every object. However
when I asked him once why, he told more or less that it was his personal
way of doing things.
However will never tell here in a newsgroup not to dispose, I tell to use
it when it has sense, however not the sentence "When there is a dipose
method it should be used".
And that is what this thread in this message as answer on Dennis started
with.
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!"
Cor
Michael, IMHO the "set of rules" remains constant, by "set of rules" I mean JD's IMHO, the "set of rules" you refer to are not rules at all; they are
Yes its a matter of perspective, not really worth splitting hairs over. :-)
I also consider JD's three & my three both to be "patterns" on one level or
another.
The "real" Dispose/Finalize pattern is the link to the Guidelines that I
posted once or twice in this thread. "Real" in that you should implement it
in your classes that is.
From what you and others have posted, this esoteric information on
Dispose() usage is gained through trial and error, from others, and of
course
I am not disputing that the situation as is, is not good.
1) Perform a lot of research to determine the Developer's Recommendations,
2) Perform a lot of research to figure out the "various exceptions",
3) Potentially spend a whole lot of time researching and adjusting your
code when the Developer Recommendations change.
It really depends on what you define to be a lot. Depending on which
framework object model I am working on, varies how much research and/or
learning I will do. For example System.String & System.Text.StringBuilder I
simply start using (I will review the documentation of specific methods from
time to time to ensure that object/method is a good fit). However the
System.Data namespace I took the time to *learn* (rather then simple
research) how the DataSet object model actually works. I would expect any
Application Architect to do the same (as oppose to simple developers, who
should be working under the guidance of an Application Architect).
Normally I don't seek out exceptions, rather I let the subtle ones find me.
This is not to say that I don't make a note of the exceptions listed on each
method in the MSDN framework reference & plan accordingly...
Imagine if you had to stop development for days each and every time you
ran across a new class that exposed Dispose(), so that you could post a
newsgroup message and await a response - which might or might not be
forthcoming. Alas, it's much simpler to consistently Dispose() of my
I would not stop development to ask! I would go to .NET Framework Reference
on MSDN & find out myself.
http://msdn.microsoft.com/library/de...pref_start.asp
For larger "object models" such as the System.Data namespace I would review
other documentation on how to actually use the types in the namespace, such
books, other MSDN, and other internet articles.
If the class reference was inconclusive, I would decide to use Dispose or
not based on what the class was doing or how much I was using the class. As
has been discussed in this thread it will not really hurt if you call
Dispose when not needed, and usually will not hurt if you don't call Dispose
when needed.
If my program was then exhibiting performance or other negative behavior I
would use CLR profiler to "give it a check up".
Tools such as CLR profiler will identify classes that probably need to have
Dispose called, by virtue of the classes that are hogging the finalization
thread. For example use the "Call Tree View" to "analyze the use of
finalizers, including the number of finalizers executed". If you are
executing finalizers, then you are probably not calling Dispose. The
following article has an example that discusses calling & not calling
SolidBrush.Dispose.
http://msdn.microsoft.com/library/de...nethowto13.asp
Of course if you are executing finalizers & don't have a Dispose method,
then the class designer probably needs to review the .NET Guidelines on the
Dispose/Finalize pattern...
Hope this helps
Jay
"Michael C#" <xy*@yomomma.com> wrote in message
news:u$**************@TK2MSFTNGP14.phx.gbl...
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:ur**************@tk2msftngp13.phx.gbl... IMHO the "set of rules" remains constant, by "set of rules" I mean JD's
three rules which are rather simple. IMHO my list of 3 are more
mantalities for managing JD's three rules...
What would change is the list classes that now either "require" or not
"require" dispose changes. I would expect classes that went from not
requiring Dispose to now requiring Dispose to directly or indirectly to
show up under the "Profiling & various exceptions" clause of my 3
rules...
IMHO, the "set of rules" you refer to are not rules at all; they are
patterns of usage. A rule would tell you, quite simply, "use Dispose() on
object x in situation y" or "don't use Dispose() on object x in situation
z". The "rules" I alluded to are the specific recommendations on usage
using pattern #3.
And I see we didn't even address my question, which is quite simply - and
to use your terms - when the "profiling & various exceptions" clause is
updated, how much time will be spent researching this, updating your usage
patterns, and finally updating any code you've currently completed?
It sounds to me like, to use pattern #3, you have to:
1) Perform a lot of research to determine the Developer's Recommendations,
2) Perform a lot of research to figure out the "various exceptions",
3) Potentially spend a whole lot of time researching and adjusting your
code when the Developer Recommendations change.
From what you and others have posted, this esoteric information on
Dispose() usage is gained through trial and error, from others, and of
course developer recommendations. It appears that there is no definitive
"list" of "classes that now either 'require' or not 'require' dispose",
and until someone puts a definitive list together, it doesn't make a lot
of sense to reference it as if it were a click away. (BTW - If it *is*
available, then this whole thread can be boiled down to a simple link to
this definitive "list"... and shame on whoever knows the whereabouts of
this list for not posting the link already).
At this point I don't see a significant ROI on all this time and energy
spent on trial-and-erroring my way to this sliver of mysterious knowledge,
researching Developer's Recommendations on using Dispose() for every class
I use, or posting a new message every single time I run across an object
that exposes a Dispose() method. After all, I tested the third option
with the SqlCommand object in this thread days ago, and still haven't
received a simple "YES" or "NO" concerning whether or not it should be
Disposed of! Instead I get responses concerning "Labels" and patterns of
usage: ("use it all the time", "use it none of the time", "use it
correctly")!
Imagine if you had to stop development for days each and every time you
ran across a new class that exposed Dispose(), so that you could post a
newsgroup message and await a response - which might or might not be
forthcoming. Alas, it's much simpler to consistently Dispose() of my
SqlCommand, SqlConnection and other objects when I'm done with them. I
would love to see a demonstration of how all the proposed research into
this arcane trivia generates anything greater than a personal sense of
accomplishment...
Of the things lacking in VB, the C#-like "using" keyword is wayyyy at
the top of my list.
As I've stated before, VB.NET 2005 will get the same "using" statement
that C# has to help manage IDisposable classes...
Good, it's about time.
Hope this helps
Maybe not in the way you think, but thank you nonetheless.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:eY*************@tk2msftngp13.phx.gbl... The GC will never directly call Dispose! The GC will only directly call
Finalize! Finalize may or may not call Dispose. Normally Dispose &
Finalize will call a common routine.
I think you mentioned "splitting hairs", Jay? Allow me to modify my
statement to the following: The Dispose() method may be called from the
Finalize() routine, which can be called by the GC; which would mean that
it's not necessarily "up to the class user" to "call this method", which was
the actual point. http://msdn.microsoft.com/library/de...izeDispose.asp
Hope that helps.
Thanks
None of your links provide a definitive list of when to call Dispose() on
classes built into the .NET Framework Library. Not even the one that
describes how to implement Dispose in your own classes.
Based on what you've said, the only reason I can see for dilly-dallying
around Dispose() and not using it every single doggone time is for bragging
rights and self-stroking of one's ego (i.e., "I have this esoteric
knowledge, so I am better than a mere 'programmer'".) The bottom line is
that you have given no substantial reason to waste time researching and
categorizing when to call, and when not to call, Dispose() on classes that
expose it.
As for learning the inner workings of classes in the .NET Framework, I
always thought the entire point of High-Level OO Programming was to provide
programmers with "clock-work" functionality that they could count on to work
consistently without having to know how many "gears were in the box", or the
specific "gear measurements", etc. After all, if everything you've created
relies on the turning of those gears, what do you do with your work when
they switch you over to a digital clock? Case in point, why in the world do
I, while programming VB.NET, need to know that the Framework sets the AH,
BX, CX, DX, SI and DS registers before an INT 21H call in order to open a
file for me?
I was under the impression that the programmer should be shielded from the
inner tinkerings of the class, and that all you really need to -- or
should -- rely on is the fact that "if I passeth in 'X' it shall performeth
'Y' and returneth 'Z'"; and that you shouldn't bet the farm on the internal
workings of a class always achieving their results in the same manner as
they appear to do today. But that's just the "programmer" in me talking,
not "Le Architect".
Sorry Cor, but I am quoting you. This is what you said. I responded to it.
You seem to keep trying to elaborate and each time, you seem to contradict
yourself. At this point, I really don't know what you are saying.
My thoughts on this are stated throughout the thread, but to sum up: I
agree that everything doesn't *need* to be disposed (labels), but data
objects most certainly do.
"Cor Ligthert" <no************@planet.nl> wrote in message
news:OG*************@TK2MSFTNGP14.phx.gbl... Scott,
"There is no need to dispose any object of system.data."
And that is what I responded to because that is untrue.
No that did I not say, because I showed you the message about connection
and any dispose method can be overridden. However, for the rest I would
not know any object in system.data that in my opinion *should* be
disposed.
About the system.data object has dispose often been in the newsgroup
Adonet. I know that Angel has advised to dispose every object. However
when I asked him once why, he told more or less that it was his personal
way of doing things.
However will never tell here in a newsgroup not to dispose, I tell to use
it when it has sense, however not the sentence "When there is a dipose
method it should be used".
And that is what this thread in this message as answer on Dennis started
with.
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!"
Cor
> Most commonly, there's an awful lot of objects that don't need to be disposed at runtime but have a visual representation of themselves in
Visual Studio that *does* need to be disposed.
Web controls are the perfect example of that. At design time, they need
to be disposed otherwise you'll squander windows resources. But at
runtime, there's nothing to dispose. Also, if you think about it,
there's no reasonable time for user code to dispose a web control at
runtime (Page.Unload maybe?).
Whoa Dave! Please explain yourself here (and in the paragraphs that
follow). You can't dispose anything at design-time, since these objects
aren't instantiated until run-time. Please don't make this topic even more
confused than it has become. Let's keep design-time out of this completely
as it is irrelevant - objects get instanced at run-time only. Run-time is
what we are talking about. The CLR isn't managing anything at design-time.
This may have been what Cor was getting at earlier. All the standard
System.Data objects: Connections, DataAdapters, DataSets, DataReaders,
none of them need to be disposed at runtime.
Nope, no, sorry, wrong, uh uh, no way, ad nauseum! You absolutely SHOULD
call dispose on OleDbConnections, OleDbDataReaders and OleDbDataAdapters as
these are all connected data objects that may very well be holding pointers
to unmanaged data providers.
It doesn't hurt anything
to call Dispose on them, it just does nothing useful (you *do* have to
close them, and Dispose will call Close for you if necessary, but that's
something else).
Again, sorry, no, nope!
But they all have visual representations that need to
be disposed at design time, so they need to implement IDisposable.
Back to my first comment. Dispose is in absolutley no way related to the
visual design-time work done in VS.NET.
Let me split some more hairs... I disagree that it is "not necessarily 'up
to the class user' to "call this method" if you are all interested in having
Dispose fire in a timely manner. Remember that without Dispose, we are at
the mercy of the GC for object clean up. The whole point of Dispose is to
avoid letting finalizes and the GC release unmanaged resources and for us to
take control of this. If we can't have deterministic finalization, we can
at least have deterministic clean-up.
This is the whole point behind Dispose. To even imply that the GC calls
dispose (when, in many situations it won't - even through the finalizer) is
mis-leading.
"Michael C#" <xy*@yomomma.com> wrote in message
news:ul**************@TK2MSFTNGP14.phx.gbl... "Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:eY*************@tk2msftngp13.phx.gbl... The GC will never directly call Dispose! The GC will only directly call
Finalize! Finalize may or may not call Dispose. Normally Dispose &
Finalize will call a common routine.
I think you mentioned "splitting hairs", Jay? Allow me to modify my
statement to the following: The Dispose() method may be called from the
Finalize() routine, which can be called by the GC; which would mean that
it's not necessarily "up to the class user" to "call this method", which
was the actual point.
http://msdn.microsoft.com/library/de...izeDispose.asp
Hope that helps.
Thanks
Then there is an imposter posting in this thread under the name "Cor",
because in a reply (in this thread) to David, you wrote:
"There is no need to dispose any object of system.data."
You do go on to say that *sometimes* you exempt the connection object. This
is already a contradiction, and I'm having a very difficult time
understanding why you are saying that you never said this when you clearly
did.
"Cor Ligthert" <no************@planet.nl> wrote in message
news:Op**************@TK2MSFTNGP10.phx.gbl... Scott,
No Cor, that is not what I'm referring to. What I've read about the
DataReader, Connection and DataAdapter classes is that they DO use
unmanaged resources and SHOULD be disposed. I'm not talking about labels
here. You said there is no reason to call dispose on any of the data
classes. I must disagree. I believe that to be incorrect.
I have never stated that the Connection not *should* be disposed for at
least a year now. So I cannot believe that you wrote is true. In opposite
of that, I am always the one who advices in these newsgroups to use that
instead of the close for the connection.
My problem in this with the dispose is, that there is always written about
unmanaged resources. However until now I never found a good link on MSDN
what they mean with an "unmanaged resource", except some blogs from by
instance old VB classic MVP's, which are often in conflict inside the
text.
Cor
"Scott M." <s-***@nospam.nospam> wrote in message
news:en**************@TK2MSFTNGP10.phx.gbl... Let me split some more hairs... I disagree that it is "not necessarily 'up
to the class user' to "call this method" if you are all interested in
having Dispose fire in a timely manner. Remember that without Dispose, we
are at the mercy of the GC for object clean up. The whole point of
Dispose is to avoid letting finalizes and the GC release unmanaged
resources and for us to take control of this. If we can't have
deterministic finalization, we can at least have deterministic clean-up.
This is the whole point behind Dispose. To even imply that the GC calls
dispose (when, in many situations it won't - even through the finalizer)
is mis-leading.
Allow me to re-split your hairs. I said that "The Dispose() method *MAY* be
called from the Finalize() routine" which is completely in line with what
Jay said "The GC will only directly call Finalize! Finalize may or may not
call Dispose."
Of course you said "To even imply that the GC calls dispose (when, in many
situations it won't - even through the finalizer) is mis-leading." Yet, at
the following link, http://msdn.microsoft.com/library/de...izeDispose.asp,
which provides guidance from MS on implementing Dispose() in your own
classes, they state:
"Provide implicit control by implementing the protected Finalize Method on
an object (destructor syntax in C# and the Managed Extensions for C++). The
garbage collector calls this method at some point after there are no longer
any valid references to the object."
And the code sample they provide includes the following chunk of code:
Protected Overrides Sub Finalize()
' Simply call Dispose(False).
Dispose (False)
End Sub
So, if it is misleading to say that the GC will call the Finalizer which
*MAY* in turn call Dispose(), why is Microsoft "misleading" us with this
statement and this code?
Are you implying, against MSDN Online, that the Finalizer never calls
Dispose()? Or that the GC never calls the Finalizer? Or are you saying
that even though the GC calls the Finalizer, Dispose() will *never* be
invoked without an explicit call from the user?
I don't dispute the article, but what I am saying is that in reality, you
can't guarantee that Finalize will call Dispose in custom class situations
where the finalizer is overriden. It is certainly possible (note: possible,
not probable or even "good idea") that a finalizer won't have a call to
dispose, in which case the GC to Finalizer to Dispose chain is broken and so
the object could be destroyed without doing its clean up.
"Michael C#" <xy*@yomomma.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl... "Scott M." <s-***@nospam.nospam> wrote in message
news:en**************@TK2MSFTNGP10.phx.gbl... Let me split some more hairs... I disagree that it is "not necessarily
'up to the class user' to "call this method" if you are all interested in
having Dispose fire in a timely manner. Remember that without Dispose,
we are at the mercy of the GC for object clean up. The whole point of
Dispose is to avoid letting finalizes and the GC release unmanaged
resources and for us to take control of this. If we can't have
deterministic finalization, we can at least have deterministic clean-up.
This is the whole point behind Dispose. To even imply that the GC calls
dispose (when, in many situations it won't - even through the finalizer)
is mis-leading.
Allow me to re-split your hairs. I said that "The Dispose() method *MAY*
be called from the Finalize() routine" which is completely in line with
what Jay said "The GC will only directly call Finalize! Finalize may or
may not call Dispose."
Of course you said "To even imply that the GC calls dispose (when, in many
situations it won't - even through the finalizer) is mis-leading." Yet,
at the following link,
http://msdn.microsoft.com/library/de...izeDispose.asp,
which provides guidance from MS on implementing Dispose() in your own
classes, they state:
"Provide implicit control by implementing the protected Finalize Method on
an object (destructor syntax in C# and the Managed Extensions for C++).
The garbage collector calls this method at some point after there are no
longer any valid references to the object."
And the code sample they provide includes the following chunk of code:
Protected Overrides Sub Finalize()
' Simply call Dispose(False).
Dispose (False)
End Sub
So, if it is misleading to say that the GC will call the Finalizer which
*MAY* in turn call Dispose(), why is Microsoft "misleading" us with this
statement and this code?
Are you implying, against MSDN Online, that the Finalizer never calls
Dispose()? Or that the GC never calls the Finalizer? Or are you saying
that even though the GC calls the Finalizer, Dispose() will *never* be
invoked without an explicit call from the user?
Just for starters: http://www.dotnet247.com/247referenc...27/136349.aspx http://www.dotnetextreme.com/code/BasicAdo.asp
"Cor Ligthert" <no************@planet.nl> wrote in message
news:Op**************@TK2MSFTNGP10.phx.gbl... Scott,
No Cor, that is not what I'm referring to. What I've read about the
DataReader, Connection and DataAdapter classes is that they DO use
unmanaged resources and SHOULD be disposed. I'm not talking about labels
here. You said there is no reason to call dispose on any of the data
classes. I must disagree. I believe that to be incorrect.
I have never stated that the Connection not *should* be disposed for at
least a year now. So I cannot believe that you wrote is true. In opposite
of that, I am always the one who advices in these newsgroups to use that
instead of the close for the connection.
My problem in this with the dispose is, that there is always written about
unmanaged resources. However until now I never found a good link on MSDN
what they mean with an "unmanaged resource", except some blogs from by
instance old VB classic MVP's, which are often in conflict inside the
text.
Cor
"Scott M." <s-***@nospam.nospam> wrote in message
news:u2**************@TK2MSFTNGP10.phx.gbl... I don't dispute the article, but what I am saying is that in reality, you
can't guarantee that Finalize will call Dispose in custom class situations
where the finalizer is overriden. It is certainly possible (note:
possible, not probable or even "good idea") that a finalizer won't have a
call to dispose, in which case the GC to Finalizer to Dispose chain is
broken and so the object could be destroyed without doing its clean up.
Which might just be why they state specifically in their article: "Do not
assume that Dispose will be called. Unmanaged resources owned by a type
should also be released in a Finalize method in the event that Dispose is
not called."
However, if we're going to get into a hair-splitting contest, let's *at the
very least* have an understanding that your statement: "It is certainly
possible (note: possible, not probable or even 'good idea') that a finalizer
won't have a call to dispose" leaves open the possibility that, in spite of
your personal feelings toward Finalize and Dispose, the Finalizer *may* ---
I repeat the word *may* for everyone's benefit here --- *may* call Dipose()!
Now, going back to the whole point of this particular branch of this rather
lengthy discussion: 1) If the GC calls the Finalizer, 2) and the Finalizer
*may*, *may*, *may* call Dispose(), then 3) This means that - despite your
misgivings about the Finalizer *potentially* calling Dispose(), it *may
just* happen. Logically, this would mean that the Dispose() method *might*,
*might*, *might* be invoked without user intervention; indirectly via the
GC, correct?
If we're going to split hairs, let's at least determine which hairs we're
splitting first. Your feeling that a Finalizer should not be trusted to
call Dispose() does not change the *fact* that a Finalizer *might* call
Dispose().
On 2005-03-21, Scott M. <s-***@nospam.nospam> wrote: Most commonly, there's an awful lot of objects that don't need to be
disposed at runtime but have a visual representation of themselves in
Visual Studio that *does* need to be disposed.
Web controls are the perfect example of that. At design time, they need
to be disposed otherwise you'll squander windows resources. But at
runtime, there's nothing to dispose. Also, if you think about it,
there's no reasonable time for user code to dispose a web control at
runtime (Page.Unload maybe?).
Whoa Dave! Please explain yourself here (and in the paragraphs that
follow). You can't dispose anything at design-time, since these objects
aren't instantiated until run-time.
Sorry, but you're wrong.
Please don't make this topic even more
confused than it has become. Let's keep design-time out of this completely
as it is irrelevant - objects get instanced at run-time only. Run-time is
what we are talking about. The CLR isn't managing anything at design-time.
Of course it is. Look, there's not point in talking theoretically.
Create a class, inherit from WebControl, pop up a messagebox in your
constructor and your Dispose override, then add that control to a
WebForm in Visual Studio. You'll see your popup. And you've been in
design-time the whole way.
Inherit from Component, you'll see the same thing.
VS has to instantiate the object, that's how VS works. How else are you
going to get properties, form display, stuff like that? Where do you
think those nice design-time displays come from. (just to note, there
are ways of having other classes handle your display, but it's not
necessary) This may have been what Cor was getting at earlier. All the standard
System.Data objects: Connections, DataAdapters, DataSets, DataReaders,
none of them need to be disposed at runtime.
Nope, no, sorry, wrong, uh uh, no way, ad nauseum! You absolutely SHOULD
call dispose on OleDbConnections, OleDbDataReaders and OleDbDataAdapters as
these are all connected data objects that may very well be holding pointers
to unmanaged data providers.
I must admit, I meant to type System.Data.SqlClient there. I went into
a bit more detail about the OleDb stuff in another post. It doesn't hurt anything
to call Dispose on them, it just does nothing useful (you *do* have to
close them, and Dispose will call Close for you if necessary, but that's
something else).
Again, sorry, no, nope!
But they all have visual representations that need to
be disposed at design time, so they need to implement IDisposable.
Back to my first comment. Dispose is in absolutley no way related to the
visual design-time work done in VS.NET.
Okay. You might want to try the exercise I mentioned.
I'm curious, if you don't believe objects are instantiated at
design-time, why do they all inherit from Component in your opinion?
What purpose could that serve at runtime?
You are confusing the VS.NET compiler and the CLR and you are making a false
assumption about Dispose based on you mis-interpreted observation.
Your "exercise" only shows what VS.NET does during design-time, not what the
CLR does at run-time and your explanation of why Dispose is there is flat
out wrong. Dispose is not there for the sake of the VS.NET design-time
interface.
Design-time is just that. While components do need to be instanced to
design them, this is a temporary design-time instance and is not comparable
to what is going on at run-time. You've connected two dots that may *seem*
like they are connectable, but in-fact, aren't.
"David" <df*****@woofix.local.dom> wrote in message
news:slrnd3tvrr.vod.df*****@woofix.local.dom... On 2005-03-21, Scott M. <s-***@nospam.nospam> wrote: Most commonly, there's an awful lot of objects that don't need to be
disposed at runtime but have a visual representation of themselves in
Visual Studio that *does* need to be disposed.
Web controls are the perfect example of that. At design time, they need
to be disposed otherwise you'll squander windows resources. But at
runtime, there's nothing to dispose. Also, if you think about it,
there's no reasonable time for user code to dispose a web control at
runtime (Page.Unload maybe?).
Whoa Dave! Please explain yourself here (and in the paragraphs that
follow). You can't dispose anything at design-time, since these objects
aren't instantiated until run-time.
Sorry, but you're wrong.
Please don't make this topic even more
confused than it has become. Let's keep design-time out of this
completely
as it is irrelevant - objects get instanced at run-time only. Run-time is
what we are talking about. The CLR isn't managing anything at
design-time.
Of course it is. Look, there's not point in talking theoretically.
Create a class, inherit from WebControl, pop up a messagebox in your
constructor and your Dispose override, then add that control to a
WebForm in Visual Studio. You'll see your popup. And you've been in
design-time the whole way.
Inherit from Component, you'll see the same thing.
VS has to instantiate the object, that's how VS works. How else are you
going to get properties, form display, stuff like that? Where do you
think those nice design-time displays come from. (just to note, there
are ways of having other classes handle your display, but it's not
necessary)
This may have been what Cor was getting at earlier. All the standard
System.Data objects: Connections, DataAdapters, DataSets, DataReaders,
none of them need to be disposed at runtime.
Nope, no, sorry, wrong, uh uh, no way, ad nauseum! You absolutely SHOULD
call dispose on OleDbConnections, OleDbDataReaders and OleDbDataAdapters
as
these are all connected data objects that may very well be holding
pointers
to unmanaged data providers.
I must admit, I meant to type System.Data.SqlClient there. I went into
a bit more detail about the OleDb stuff in another post.
It doesn't hurt anything
to call Dispose on them, it just does nothing useful (you *do* have to
close them, and Dispose will call Close for you if necessary, but that's
something else).
Again, sorry, no, nope!
But they all have visual representations that need to
be disposed at design time, so they need to implement IDisposable.
Back to my first comment. Dispose is in absolutley no way related to the
visual design-time work done in VS.NET.
Okay. You might want to try the exercise I mentioned.
I'm curious, if you don't believe objects are instantiated at
design-time, why do they all inherit from Component in your opinion?
What purpose could that serve at runtime?
I think you are putting words (or opinions) into my mouth when all I was
trying to do was make a point. See inline:
"Michael C#" <xy*@yomomma.com> wrote in message
news:ux**************@TK2MSFTNGP09.phx.gbl... "Scott M." <s-***@nospam.nospam> wrote in message
news:u2**************@TK2MSFTNGP10.phx.gbl...I don't dispute the article, but what I am saying is that in reality, you
can't guarantee that Finalize will call Dispose in custom class situations
where the finalizer is overriden. It is certainly possible (note:
possible, not probable or even "good idea") that a finalizer won't have a
call to dispose, in which case the GC to Finalizer to Dispose chain is
broken and so the object could be destroyed without doing its clean up.
Which might just be why they state specifically in their article: "Do not
assume that Dispose will be called. Unmanaged resources owned by a type
should also be released in a Finalize method in the event that Dispose is
not called."
True, but you must acknowledge that in this case, you have no control over
when that *may* happen. Kinda useless if that's the case right?
However, if we're going to get into a hair-splitting contest, let's *at
the very least* have an understanding that your statement: "It is
certainly possible (note: possible, not probable or even 'good idea') that
a finalizer won't have a call to dispose" leaves open the possibility
that, in spite of your personal feelings toward Finalize and Dispose, the
Finalizer *may* --- I repeat the word *may* for everyone's benefit
here --- *may* call Dipose()!
Yep, and that's the same thing I said when I added "(not probable)".
Now, going back to the whole point of this particular branch of this
rather lengthy discussion: 1) If the GC calls the Finalizer, 2) and the
Finalizer *may*, *may*, *may* call Dispose(), then 3) This means that -
despite your misgivings about the Finalizer *potentially* calling
Dispose(), it *may just* happen. Logically, this would mean that the
Dispose() method *might*, *might*, *might* be invoked without user
intervention; indirectly via the GC, correct?
If we're going to split hairs, let's at least determine which hairs we're
splitting first. Your feeling that a Finalizer should not be trusted to
call Dispose() does not change the *fact* that a Finalizer *might* call
Dispose().
I think you are looking for a hair to split on a bald man at this point
since you are just repeating what I said.
On 2005-03-22, Scott M. <s-***@nospam.nospam> wrote: You are confusing the VS.NET compiler and the CLR and you are making a false
assumption about Dispose based on you mis-interpreted observation.
Your "exercise" only shows what VS.NET does during design-time, not what the
CLR does at run-time
With all due respect, that makes absolutely no sense at all. As far as
the CLR is concerned, it *is* runtime. The CLR couldn't care less what
application is instantiating an object. VS.Net is just another
application in this case.
"Design-time" in this sense is simply an artifact of the Framework
libraries, it's the presence of a few properties in a few base classes.
As far as the CLR is concerned, your code is running, it's runtime.
and your explanation of why Dispose is there is flat
out wrong. Dispose is not there for the sake of the VS.NET design-time
interface.
Design-time is just that. While components do need to be instanced to
design them, this is a temporary design-time instance and is not comparable
to what is going on at run-time.
What's the difference, and what do you think "temporary" means in that
sentence? Is there some kind of special "non-temporary" instantiation
that happens at other times?
It what possible way is it not comparable to runtime?
Your class has been instantiated. The GC will collect your class at
some point. Dispose will be called if you implement it. Various
properties and methods you define will be called. Your code is running,
and you may have aggregated unmanaged resources in your constructor
which means they need to be disposed. Face it, that's runtime.
You've connected two dots that may *seem*
like they are connectable, but in-fact, aren't.
You're long on flat statements, but very short on anything backing them
up.
What's your point exactly? Are you implying that VS.Net *doesn't* need
to call Dispose on custom controls and components instantiated in
designers? Why not?
On 2005-03-21, Michael C# <xy*@yomomma.com> wrote:
After all, I tested the third option with the
SqlCommand object in this thread days ago, and still haven't received a
simple "YES" or "NO" concerning whether or not it should be Disposed of!
OK, a simple answer. Disposing a SqlCommand does absolutely nothing
except take up time. It's a no-op.
Instead I get responses concerning "Labels" and patterns of usage: ("use it
all the time", "use it none of the time", "use it correctly")!
Imagine if you had to stop development for days each and every time you ran
across a new class that exposed Dispose(), so that you could post a
newsgroup message and await a response - which might or might not be
forthcoming.
I see your general point here, but in practice it's not that tough. In
day-to-day programming, I pretty much deal with only four types of
objects:
Web controls, which never need to be disposed.
Forms controls, which should always be disposed.
Data library objects, and since there's only a few of them I tend to
know the ones I'm working with pretty damn well since I'm hitting the db
all day long, and so I have a pretty good sense as to whether I want to
dispose them and when.
Things that derive from Component, which generally don't need to be
disposed, but it only takes a moment to figure out if the class actually
implements a Dispose function, so in practice that's not a problem.
Alas, it's much simpler to consistently Dispose() of my
SqlCommand, SqlConnection and other objects when I'm done with them. I
would love to see a demonstration of how all the proposed research into this
arcane trivia generates anything greater than a personal sense of
accomplishment...
I actually think avoiding the Dispose calls makes code a lot cleaner. This thread has been closed and replies have been disabled. Please start a new discussion. |
