Dispose Again!

[David]

Re: Dispose Again!

On 2005-03-22, Michael C# <xyz@abcdef.com > wrote:[color=blue]
>
> "David" <dfoster@woofix .local.dom> wrote in message
> news:slrnd3u6f2 .vtv.dfoster@wo ofix.local.dom. ..[color=green]
>> On 2005-03-21, Michael C# <xyz@yomomma.co m> wrote:[color=darkred]
>>>
>>> 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![/color]
>>
>> OK, a simple answer. Disposing a SqlCommand does absolutely nothing
>> except take up time. It's a no-op.
>>[/color]
>
> Thank you! Finally a straight answer! My next question is this: is the
> optimizer smart enough to figure this out and discard the no-op?[/color]

I don't see how, that's why it takes up (a little) time. There's a lock
and a few tests involved.
[color=blue][color=green]
>> 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.[/color]
>
> Now see, this is where the confusion comes in. You say Forms controls
> should always be disposed - yet others say Dispose is not necessary on a
> Label... Is the Label an "exception" ? Or should Forms controls, including
> the Label, be disposed?[/color]

In practice, it's really not an issue for me. I add it to components
and I know the components will be disposed for me. I realize there are
designs where this is a real issue, but so far it's just not an issue to
me.
[color=blue]
> Also, at the end you mention "it only takes a moment to figure out if the
> class actually implements a Dispose function..." which takes us full circle
> to the crux of the matter - some say that not everything that implements a
> Dispose needs to be Disposed. The question is which Components that expose
> a Dispose method need to have Dispose called on them?[/color]

I know what Component.Dispo se does, and MarshallByRefCo mponent.Dispose , etc. So
the only issue is whether the class itself implements a needed Dispose
override, and that only takes a second to check.

[color=blue][color=green][color=darkred]
>>> 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. ..[/color]
>>
>> I actually think avoiding the Dispose calls makes code a lot cleaner.[/color]
>
> That may be true, but I think it may be short-term thinking. Per another
> message in here, if the SqlCommand, for instance, were to be implemented
> differently in the future - and the Developer suddenly recommends the use of
> Dispose - you will have to re-tool your design patterns and re-work your
> code.[/color]

And I do worry about that, but there's a flipside. I see a lot of code
that does a premature Dispose that only works because Dispose doesn't
really do anything. If some class I'm calling suddenly implement a
truly destructive dispose, my code might have a few temporary leaks but
that's better than simply crashing. And I do somewhat trust that decent
programmers will implement Finalize correctly.

I'm not saying this is right, just that it's a trade-off. Dispose is
basically a hole in the Framework due to (necessary) limitations of the
GC. I don't think there's a simple one-size-fits-all solution to it.

[Jay B. Harlow [MVP - Outlook]]

Re: Dispose Again!

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

I have not given a substantial reason as IMHO there is no substantial
reason! I believe I stated (at least implied) I would not waste time
researching & categorizing when to call or not call Dispose.

As JD, David & myself have tried to state: We work with a certain set of
classes, by experience we have learned which need to be disposed & which do
not.
[color=blue]
> As for learning the inner workings of classes in the .NET Framework, I[/color]
I don't believe I stated inner workings, I definitely did not mean to imply
inner workings, as I consider inner workings as implementation details that
are subject to change. What I intended on stating is that you need to learn
the "intent" or the workings of the class! I hope you agree that learning
the intent of a class is important before you just start "throwing code
together".

Hope this helps
Jay




"Michael C#" <xyz@yomomma.co m> wrote in message
news:eEYp%23plL FHA.576@TK2MSFT NGP15.phx.gbl.. .[color=blue]
> 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".
>[/color]

[Michael C#]

Re: Dispose Again!


"David" <dfoster@woofix .local.dom> wrote in message
news:slrnd3ubju .fa.dfoster@woo fix.local.dom.. .[color=blue]
> On 2005-03-22, Michael C# <xyz@abcdef.com > wrote:[color=green]
>> Now see, this is where the confusion comes in. You say Forms controls
>> should always be disposed - yet others say Dispose is not necessary on a
>> Label... Is the Label an "exception" ? Or should Forms controls,
>> including
>> the Label, be disposed?[/color]
>
> In practice, it's really not an issue for me. I add it to components
> and I know the components will be disposed for me. I realize there are
> designs where this is a real issue, but so far it's just not an issue to
> me.[/color]

This wasn't an issue for me either, until I was informed that I was wrong.
This is another item that I don't have time to waste contemplating theory
versus practice. I'll just let the Forms Designer generated code handle the
Dispose's on Forms controls and call it a day.
[color=blue][color=green]
>> Also, at the end you mention "it only takes a moment to figure out if the
>> class actually implements a Dispose function..." which takes us full
>> circle
>> to the crux of the matter - some say that not everything that implements
>> a
>> Dispose needs to be Disposed. The question is which Components that
>> expose
>> a Dispose method need to have Dispose called on them?[/color]
>
> I know what Component.Dispo se does, and MarshallByRefCo mponent.Dispose ,
> etc. So
> the only issue is whether the class itself implements a needed Dispose
> override, and that only takes a second to check.[/color]

This is the information I need! How do you determine if a class implements
a *needed* Dispose override, as opposed to an unnecessary one? So far I've
been given the run-around on this particular question with a lot of
inadequate answers. If I could get a solid definitive answer on this one
question, it would pretty much answer everything. It seems you have to
"know the secret 'Brotherhood of Le Architects' handshake" in order to get
this one particular piece of information.
[color=blue]
> And I do worry about that, but there's a flipside. I see a lot of code
> that does a premature Dispose that only works because Dispose doesn't
> really do anything. If some class I'm calling suddenly implement a
> truly destructive dispose, my code might have a few temporary leaks but
> that's better than simply crashing. And I do somewhat trust that decent
> programmers will implement Finalize correctly.[/color]

That makes sense, although I haven't encountered that problem to date - and
I'd think that a destructive Dispose would make itself known via crashing,
etc., far before the product made its way out of development. But stranger
things have happened I suppose. How much of a memory leak you're willing to
tolerate probably depends on a lot of factors, I would imagine.
[color=blue]
> I'm not saying this is right, just that it's a trade-off. Dispose is
> basically a hole in the Framework due to (necessary) limitations of the
> GC. I don't think there's a simple one-size-fits-all solution to it.[/color]

I think the best solution, from my point of view, would be better
information about when - and when not - to call it. As of now it seems like
quite a hindrance.

[Scott M.]

Re: Dispose Again!

> "It is up to the class user to call this method [Dispose]."[color=blue]
>
> My original point, as desmonstrated by the Microsoft(tm)-sponsored
> statement and code previously posted, is that the Finalize method can call
> Dispose. The Finalize method is called via the GC. The GC normally is not
> invoked by the "class user". It *can* happen; therefore the statement is
> False.[/color]

Uh, well, if in your book can=false, then ok. In my book, if I build a
custom class that inherits from object and I create a Dispose method for it,
the GC isn't going to do squat as far as calling my Dispose method. So,
would I be wrong to reverse your logic and say that because it *might not*
get called, my statement is true? Sure!

[Scott M.]

Re: Dispose Again!

You have heard if from the horses mouth, over and over in this thread:

When a class uses unmanaged resources and exposes a Dispose method, call the
Dispose method.

This is what virtually all documentation on Dispose says. The rest of this
thread is academic.


"Michael C#" <xyz@abcdef.com > wrote in message
news:oOK%d.785$ 7P6.670@fe10.lg a...[color=blue]
> Has anyone from Microsoft itself weighed in on this, or are the
> MS-employed Developers steering clear of this train wreck? I personally
> would like to hear it from the horse's mouth once and for all.
>[/color]

[Michael C#]

Re: Dispose Again!


"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
news:%23asM7VpL FHA.244@TK2MSFT NGP12.phx.gbl.. .[color=blue]
> Michael,[color=green]
>> 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.[/color]
> Exactly!!!!!
>
> I have not given a substantial reason as IMHO there is no substantial
> reason! I believe I stated (at least implied) I would not waste time
> researching & categorizing when to call or not call Dispose.
>
> As JD, David & myself have tried to state: We work with a certain set of
> classes, by experience we have learned which need to be disposed & which
> do not.[/color]

So basically, a beginning programmer can expect to put out potentially
problematic, sub-optimal code full of memory leaks until they learn [by
experience alone??] "which need to be disposed & which do not." That's
definitely a sub-optimal answer.
[color=blue][color=green]
>> As for learning the inner workings of classes in the .NET Framework, I[/color]
> I don't believe I stated inner workings, I definitely did not mean to
> imply inner workings, as I consider inner workings as implementation
> details that are subject to change. What I intended on stating is that you
> need to learn the "intent" or the workings of the class! I hope you agree
> that learning the intent of a class is important before you just start
> "throwing code together".[/color]

I apologize if I misunderstood your statement that "However the System.Data
namespace I took the time to *learn* (rather then simple research) how the
DataSet object model actually works." As for the "intent", perhaps you
could explain further? I'm sure you don't mean by "intent" that the
"SqlConnect ion" class has the "intent" of allowing you to connect to a SQL
Server database. Or that the "Label" class has the "intent" of displaying
text. If this is the "intent", I'm sure MSDN Online is more than adequate
in detailing it. If "intent" is rather some arcane bit of trivia pertaining
to particular methods of a particular class...

[Jay B. Harlow [MVP - Outlook]]

Re: Dispose Again!

Michael,
I sent a question or two to MS on this. I will post here if I get anthing to
satiate your questions & concerns....

Hope this helps
Jay

"Michael C#" <xyz@abcdef.com > wrote in message
news:oOK%d.785$ 7P6.670@fe10.lg a...[color=blue]
> Has anyone from Microsoft itself weighed in on this, or are the
> MS-employed Developers steering clear of this train wreck? I personally
> would like to hear it from the horse's mouth once and for all.
>[/color]

[Scott M.]

Re: Dispose Again!

Your saying that the purpose of Dispose on components is for VS.NET's sake
and not for the running application's sake because VS.NET is causing the
component to hold on to unmanaged resources. What unmanaged resources does
a label or textbox hold on to that VS.NET must dispose of?

Your saying that Dispose is present because of the IDE and not the final
running application and that in that final running application, Dispose has
no use. That is what I take issue with, that is what is completely false.

Dispose does not exist as some sort of clean up tool for VS.NET.

"David" <dfoster@woofix .local.dom> wrote in message
news:slrnd3u57j .vtv.dfoster@wo ofix.local.dom. ..[color=blue]
> On 2005-03-22, Scott M. <s-mar@nospam.nosp am> wrote:[color=green]
>> 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[/color]
>
> 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.
>[color=green]
>> 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.[/color]
>
> 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.
>[color=green]
>> You've connected two dots that may *seem*
>> like they are connectable, but in-fact, aren't.[/color]
>
> 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?
>
>
>
>
>[/color]

[David]

Re: Dispose Again!

On 2005-03-22, Michael C# <xyz@abcdef.com > wrote:[color=blue]
>
> "David" <dfoster@woofix .local.dom> wrote in message
> news:slrnd3ubju .fa.dfoster@woo fix.local.dom.. .[color=green]
>> On 2005-03-22, Michael C# <xyz@abcdef.com > wrote:[color=darkred]
>>> Now see, this is where the confusion comes in. You say Forms controls
>>> should always be disposed - yet others say Dispose is not necessary on a
>>> Label... Is the Label an "exception" ? Or should Forms controls,
>>> including
>>> the Label, be disposed?[/color]
>>
>> I know what Component.Dispo se does, and MarshallByRefCo mponent.Dispose ,
>> etc. So
>> the only issue is whether the class itself implements a needed Dispose
>> override, and that only takes a second to check.[/color]
>
> This is the information I need! How do you determine if a class implements
> a *needed* Dispose override, as opposed to an unnecessary one? So far I've
> been given the run-around on this particular question with a lot of
> inadequate answers.[/color]

Personally, I just pull up Reflector (or even ildasm) and look at the
class. IL is pretty readable. Often, component-derived classes don't
even implement Dispose, it's just there from the base class.
[color=blue]
> That makes sense, although I haven't encountered that problem to date - and
> I'd think that a destructive Dispose would make itself known via crashing,
> etc., far before the product made its way out of development.[/color]

Well, that assumes we're in development. For example, I tend to load a
lot of things through reflection, so I can't really be sure what I'm
getting during development is what I'm getting in production.

But for the most part, we're probably talking about a new version of
..NET, and for that I expect major dispose changes to be fairly well
known (if not documented by MS, they'll still show up on mailing lists,
etc.).
[color=blue]
> But stranger
> things have happened I suppose. How much of a memory leak you're willing to
> tolerate probably depends on a lot of factors, I would imagine.
>[color=green]
>> I'm not saying this is right, just that it's a trade-off. Dispose is
>> basically a hole in the Framework due to (necessary) limitations of the
>> GC. I don't think there's a simple one-size-fits-all solution to it.[/color]
>
> I think the best solution, from my point of view, would be better
> information about when - and when not - to call it. As of now it seems like
> quite a hindrance.[/color]

Agreed. For example, here's a nagging question. If I don't dispose an
IDbConnection, am I holding onto resources too long? But if I do
dispose it, what effect does that have on the connection pool
(presumably the pool can't reuse a Disposed connection, right?).

There's really no way to answer that without knowing the internals of
the class, but the whole point of using the interface (instead of a
concrete class) in the first place was so that my code didn't have to
know the internals of the class.

That's a problem I still haven't figured out a decent answer to.

[David]

Re: Dispose Again!

On 2005-03-22, Scott M. <s-mar@nospam.nosp am> wrote:[color=blue]
> Your saying that the purpose of Dispose on components is for VS.NET's sake
> and not for the running application's sake because VS.NET is causing the
> component to hold on to unmanaged resources. What unmanaged resources does
> a label or textbox hold on to that VS.NET must dispose of?[/color]

Quite often, a visual representation of itself which might consume GDI
resources. Database objects tend to hold onto a connection to the
database. More to the point, there's no way for VS.NET to know what
unmanaged resources the object is holding onto.
[color=blue]
>
> Your saying that Dispose is present because of the IDE and not the final
> running application and that in that final running application, Dispose has
> no use.[/color]

I'm saying that's true in some cases.
[color=blue]
> That is what I take issue with, that is what is completely false.[/color]

Well, gee, it's hard to argue with that impeccable logic. And you've
backed up your argument so well here with, well, pretty much nothing.
[color=blue]
> Dispose does not exist as some sort of clean up tool for VS.NET.[/color]

Dispose exists as, essentially, a clean up mechanism for consumers of a
class. VS.Net is one such consumer. VS.Net also has special needs at
design-time, that's exactly why there's a mechanism for classes to know
whether they're running under a design-time environment, so that they
can alter their behavior in that environment. Some objects need
different Dispose behavior depending on their environment.

This really isn't complex or controversial stuff. It's pretty basic.

[Cor Ligthert]

Re: Dispose Again!

doh,

Jay,

Forget it, this I have long ago checked with debugging, it is done by the
close. I became confused by this discussion.

Cor

[Jay B. Harlow [MVP - Outlook]]

Re: Dispose Again!

Doh!
[color=blue]
> are subject to change. What I intended on stating is that you need to
> learn the "intent" or the workings of the class![/color]
That should read "the "intent" or outer workings of the class

Jay

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
news:%23asM7VpL FHA.244@TK2MSFT NGP12.phx.gbl.. .[color=blue]
> Michael,[color=green]
>> 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.[/color]
> Exactly!!!!!
>
> I have not given a substantial reason as IMHO there is no substantial
> reason! I believe I stated (at least implied) I would not waste time
> researching & categorizing when to call or not call Dispose.
>
> As JD, David & myself have tried to state: We work with a certain set of
> classes, by experience we have learned which need to be disposed & which
> do not.
>[color=green]
>> As for learning the inner workings of classes in the .NET Framework, I[/color]
> I don't believe I stated inner workings, I definitely did not mean to
> imply inner workings, as I consider inner workings as implementation
> details that are subject to change. What I intended on stating is that you
> need to learn the "intent" or the workings of the class! I hope you agree
> that learning the intent of a class is important before you just start
> "throwing code together".
>
> Hope this helps
> Jay
>
>
>
>
> "Michael C#" <xyz@yomomma.co m> wrote in message
> news:eEYp%23plL FHA.576@TK2MSFT NGP15.phx.gbl.. .[color=green]
>> 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".
>>[/color]
>
>[/color]

[Jay B. Harlow [MVP - Outlook]]

Re: Dispose Again!

Michael,[color=blue]
> This is the information I need! How do you determine if a class
> implements a *needed* Dispose override, as opposed to an unnecessary one?
> So far I've[/color]
In addition to the list of class members in MSDN Online & ILDASM or
Reflector that David mentions, you can use Object Browser in VS.NET.

Jay

"Michael C#" <xyz@abcdef.com > wrote in message
news:U8N%d.818$ tE4.171@fe10.lg a...[color=blue]
>
> "David" <dfoster@woofix .local.dom> wrote in message
> news:slrnd3ubju .fa.dfoster@woo fix.local.dom.. .[color=green]
>> On 2005-03-22, Michael C# <xyz@abcdef.com > wrote:[color=darkred]
>>> Now see, this is where the confusion comes in. You say Forms controls
>>> should always be disposed - yet others say Dispose is not necessary on a
>>> Label... Is the Label an "exception" ? Or should Forms controls,
>>> including
>>> the Label, be disposed?[/color]
>>
>> In practice, it's really not an issue for me. I add it to components
>> and I know the components will be disposed for me. I realize there are
>> designs where this is a real issue, but so far it's just not an issue to
>> me.[/color]
>
> This wasn't an issue for me either, until I was informed that I was wrong.
> This is another item that I don't have time to waste contemplating theory
> versus practice. I'll just let the Forms Designer generated code handle
> the Dispose's on Forms controls and call it a day.
>[color=green][color=darkred]
>>> Also, at the end you mention "it only takes a moment to figure out if
>>> the
>>> class actually implements a Dispose function..." which takes us full
>>> circle
>>> to the crux of the matter - some say that not everything that implements
>>> a
>>> Dispose needs to be Disposed. The question is which Components that
>>> expose
>>> a Dispose method need to have Dispose called on them?[/color]
>>
>> I know what Component.Dispo se does, and MarshallByRefCo mponent.Dispose ,
>> etc. So
>> the only issue is whether the class itself implements a needed Dispose
>> override, and that only takes a second to check.[/color]
>
> This is the information I need! How do you determine if a class
> implements a *needed* Dispose override, as opposed to an unnecessary one?
> So far I've been given the run-around on this particular question with a
> lot of inadequate answers. If I could get a solid definitive answer on
> this one question, it would pretty much answer everything. It seems you
> have to "know the secret 'Brotherhood of Le Architects' handshake" in
> order to get this one particular piece of information.
>[color=green]
>> And I do worry about that, but there's a flipside. I see a lot of code
>> that does a premature Dispose that only works because Dispose doesn't
>> really do anything. If some class I'm calling suddenly implement a
>> truly destructive dispose, my code might have a few temporary leaks but
>> that's better than simply crashing. And I do somewhat trust that decent
>> programmers will implement Finalize correctly.[/color]
>
> That makes sense, although I haven't encountered that problem to date -
> and I'd think that a destructive Dispose would make itself known via
> crashing, etc., far before the product made its way out of development.
> But stranger things have happened I suppose. How much of a memory leak
> you're willing to tolerate probably depends on a lot of factors, I would
> imagine.
>[color=green]
>> I'm not saying this is right, just that it's a trade-off. Dispose is
>> basically a hole in the Framework due to (necessary) limitations of the
>> GC. I don't think there's a simple one-size-fits-all solution to it.[/color]
>
> I think the best solution, from my point of view, would be better
> information about when - and when not - to call it. As of now it seems
> like quite a hindrance.
>[/color]

[Jay B. Harlow [MVP - Outlook]]

Re: Dispose Again!

Cor,
That section of code is explained here:

http://www.vbinfozine.com/a_disposable_comp.shtml

Hope this helps
Jay

"Cor Ligthert" <notmyfirstname @planet.nl> wrote in message
news:OjGWJmrLFH A.2796@tk2msftn gp13.phx.gbl...[color=blue]
> Jay,
>
> When you do that will you than as well implement this in your message.
> This is in almost in every way in a class that implements Idisposable
>
> \\\
> 'Form overrides dispose to clean up the component list.
> Protected Overloads Overrides Sub Dispose(ByVal disposing As Boolean)
> If disposing Then
> If Not (components Is Nothing) Then
> components.Disp ose()
> End If
> End If
> MyBase.Dispose( disposing)
> End Sub
> Private components As System.Componen tModel.IContain er
> ///
>
> And therefore as well in every form, which means in my opinion that every
> component will be disposed by a form close (However we can not reach that
> in the standard situation without an explicit sub main, what than again
> would mean that with a sub main that should be done for a form
> explicitly).
>
> That is for me a question which is still open, what is the logic behind
> this.
>
> Cor.
>
>
>
>
>[/color]

[Michael C#]

Re: Dispose Again!


"Scott M." <s-mar@nospam.nosp am> wrote in message
news:OvM5yfpLFH A.4084@TK2MSFTN GP10.phx.gbl...[color=blue][color=green]
>> "It is up to the class user to call this method [Dispose]."
>>
>> My original point, as desmonstrated by the Microsoft(tm)-sponsored
>> statement and code previously posted, is that the Finalize method can
>> call Dispose. The Finalize method is called via the GC. The GC normally
>> is not invoked by the "class user". It *can* happen; therefore the
>> statement is False.[/color]
>
> Uh, well, if in your book can=false, then ok.[/color]

In my book the statement "It is up to the class user to call this method" =
false, as it is a documented fact that Dispose can be invoked by means other
than the "class user". Too easy Breezy.
[color=blue]
> In my book, if I build a custom class that inherits from object and I
> create a Dispose method for it, the GC isn't going to do squat as far as
> calling my Dispose method. So, would I be wrong to reverse your logic and
> say that because it *might not* get called, my statement is true? Sure![/color]

If you invoke Dispose in the Finalize method, as Microsoft has done in the
previously supplied sample code, then there is the possibility that it can
be invoked by GC. If you don't, then for that *one particular class*, it
cannot happen. However, based on the wild assumption that you're not the
only person in the Universe developing classes for the Framework (or just
maybe you are?) and that not everyone does things precisely the way you do
(some might even use Microsoft's own sample code as a starting point...
then again, this could be another wild and crazy out-of-bounds assumption),
it seems reasonable to conclude that there is at least one class out there
in the world in which the Finalize method invokes Dispose. That one,
single, lonely class which was not developed the "Scott M Way" makes your
gross generalization "false".