Dispose Again!

[Cor Ligthert]

Re: Dispose Again!

Jay,
[color=blue]
> Honestly Cor, I have seriously wonder if you are smoking something or
> popping some pills here as you are making zero sense!
>[/color]

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

[Cor Ligthert]

Re: Dispose Again!

> This means. that what you write should be done, this is about class that[color=blue]
> derives from this list and those classes themselves.
>[/color]
This means that what you write should be done for all classes that by
instance derive from components.

This........... ...............

[Cor Ligthert]

Re: Dispose Again!

Scott,

Maybe it is good to remind that I wrote this in my starting answer.
[color=blue]
>Therefore I inherit from components when I make a class from which I have
>slightly the idea that it has unmanaged resources in it.[/color]

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

[JD]

Re: Dispose Again!

> Calling a dispose individualy explicitly (in classes where Idispose is[color=blue]
> implemented) optimezes the process of garbage collection. However the GC[/color]
is[color=blue]
> 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.[/color]

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!

[JD]

Re: Dispose Again!

> 1) Never call Dispose, instead let the Finalizer take care of unmanaged[color=blue]
> resources. This is probably the worst & sloppiest attitude you can take on
> calling Dispose. Profiling & various exceptions will indicate problems[/color]
when[color=blue]
> using this method.
>
> 2) Always call Dispose, the "better safe then sorry" pattern.
>
> 3) "Appropriat ely" 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...[/color]


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.

[Jay B. Harlow [MVP - Outlook]]

Re: Dispose Again!

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!

[color=blue]
> You have lost all your credits from me.[/color]
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" <notmyfirstname @planet.nl> wrote in message
news:ejTOAfSLFH A.3380@TK2MSFTN GP15.phx.gbl...[color=blue]
> Jay,
>[color=green]
>> Honestly Cor, I have seriously wonder if you are smoking something or
>> popping some pills here as you are making zero sense!
>>[/color]
>
> 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
>[/color]

[Michael C#]

Re: Dispose Again!

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/microsoft.public.dotnet.framework.adonet/messages/a703ff443f88eedb,4c9705927efc284f,e19d37258d51b547,1b8aac7e3c7d7926,8c94dbec57fbf542,8e04f7450df8d503,31183b7d35022c67,bf677cee43661d21,01e5f2f511b2f7bd,c256a645b44e4405?thread_id=bccef99d2d0bfb21&mode=thread&noheader=1&q=%22connection+pooling%22+sahil+malik#doc_01e5f2f511b2f7bd

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" <anonymous@disc ussions.microso ft.com> wrote in message
news:DLKdnUyuZv rs5KDfRVn-jw@comcast.com. ..[color=blue][color=green]
>> 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[/color]
> when[color=green]
>> using this method.
>>
>> 2) Always call Dispose, the "better safe then sorry" pattern.
>>
>> 3) "Appropriat ely" 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...[/color]
>
>
> 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.
>
>[/color]

[Michael C#]

Re: Dispose Again!

Yeah Cor, I just visited that new link and I still don't see how it relates?

"Cor Ligthert" <notmyfirstname @planet.nl> wrote in message
news:uBcm4zRLFH A.688@TK2MSFTNG P10.phx.gbl...[color=blue]
> 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
>[/color]

[Scott M.]

Re: Dispose Again!

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" <notmyfirstname @planet.nl> wrote in message
news:eTACrPULFH A.724@TK2MSFTNG P14.phx.gbl...[color=blue]
> Scott,
>
> Maybe it is good to remind that I wrote this in my starting answer.
>[color=green]
>>Therefore I inherit from components when I make a class from which I have
>>slightly the idea that it has unmanaged resources in it.[/color]
>
> 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
>[/color]

[Scott M.]

Re: Dispose Again!

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#" <xyz@abcdef.com > wrote in message
news:ZW%_d.9691 $4_4.6117@fe10. lga...[color=blue]
> "Scott M." <s-mar@nospam.nosp am> wrote in message
> news:e%23GTg3KL FHA.3104@TK2MSF TNGP14.phx.gbl. ..[color=green][color=darkred]
>>> If I understand Dispose() correctly, it simply forces the .NET framework
>>> to mark an object for Garbage Collection.[/color]
>>
>> Not necessarially. An object is marked for collection when nothing is
>> pointing at it any longer.[/color]
>
> What does Dispose() do exactly?
>[color=green]
>>[color=darkred]
>>>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.[/color]
>>
>> 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).[/color]
>
> 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?
>[color=green][color=darkred]
>>> 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?[/color]
>>
>> 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.[/color]
>
> 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?
>[/color]

[Michael C#]

Re: Dispose Again!

"Scott M." <s-mar@nospam.nosp am> wrote in message
news:uDN%23eqZL FHA.3832@TK2MSF TNGP12.phx.gbl. ..[color=blue]
> 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.
>[/color]

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".

[Scott M.]

Re: Dispose Again!

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 (OleDbConnectio n, 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#" <xyz@abcdef.com > wrote in message
news:VVn%d.2374 $kE5.1552@fe08. lga...[color=blue]
> "Scott M." <s-mar@nospam.nosp am> wrote in message
> news:uDN%23eqZL FHA.3832@TK2MSF TNGP12.phx.gbl. ..[color=green]
>> 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.
>>[/color]
>
> 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".
>[/color]

[Scott M.]

Re: Dispose Again!

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" <notmyfirstname @planet.nl> wrote in message
news:O8i%23nQSL FHA.2764@tk2msf tngp13.phx.gbl. ..[color=blue]
> 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
>
>[/color]

[Jay B. Harlow [MVP - Outlook]]

Re: Dispose Again!

Michael,[color=blue]
> 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[/color]
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...

[color=blue]
> Of the things lacking in VB, the C#-like "using" keyword is wayyyy at the
> top of my list.[/color]
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#" <xyz@abcdef.com > wrote in message
news:Huj%d.1512 $sO.941@fe08.lg a...[color=blue]
> 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" <anonymous@disc ussions.microso ft.com> wrote in message
> news:DLKdnUyuZv rs5KDfRVn-jw@comcast.com. ..[color=green][color=darkred]
>>> 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[/color]
>> when[color=darkred]
>>> using this method.
>>>
>>> 2) Always call Dispose, the "better safe then sorry" pattern.
>>>
>>> 3) "Appropriat ely" 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...[/color]
>>
>>
>> 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.
>>
>>[/color]
>
>[/color]

[Jay B. Harlow [MVP - Outlook]]

Re: Dispose Again!

Michael,[color=blue]
> I was under the mistaken impression that the GC could call Dispose(), as
> well as the "class user".[/color]
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/default.asp?url=/library/en-us/cpgenref/html/cpconFinalizeDispose.asp

Hope this helps
Jay

"Michael C#" <xyz@abcdef.com > wrote in message
news:VVn%d.2374 $kE5.1552@fe08. lga...[color=blue]
> "Scott M." <s-mar@nospam.nosp am> wrote in message
> news:uDN%23eqZL FHA.3832@TK2MSF TNGP12.phx.gbl. ..[color=green]
>> 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.
>>[/color]
>
> 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".
>[/color]