473,842 Members | 1,658 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Dispose Again!

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.dosomet hingmethod(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 mydisposableobj ect as new object 2
object1.dosomet hingmethod(mydi sposableobject )
myotherobject.D ispose
--
Dennis in Houston
Nov 21 '05
156 5936

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:%2******** *******@TK2MSFT NGP12.phx.gbl.. .
Michael,
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.

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.


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.
As for learning the inner workings of classes in the .NET Framework, I

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


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...
Nov 21 '05 #111
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#" <xy*@abcdef.com > wrote in message
news:oO******** *******@fe10.lg a...
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.

Nov 21 '05 #112
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" <df*****@woofix .local.dom> wrote in message
news:slrnd3u57j .vtv.df*****@wo ofix.local.dom. ..
On 2005-03-22, Scott M. <s-***@nospam.nosp am> 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?


Nov 21 '05 #113
On 2005-03-22, Michael C# <xy*@abcdef.com > wrote:

"David" <df*****@woofix .local.dom> wrote in message
news:slrnd3ubju .fa.df*****@woo fix.local.dom.. .
On 2005-03-22, Michael C# <xy*@abcdef.com > wrote:
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?
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.


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.


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


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.


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.
Nov 21 '05 #114
On 2005-03-22, Scott M. <s-***@nospam.nosp am> wrote:
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?
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.

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.
I'm saying that's true in some cases.
That is what I take issue with, that is what is completely false.
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.
Dispose does not exist as some sort of clean up tool for VS.NET.


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.
Nov 21 '05 #115
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
Nov 21 '05 #116
Doh!
are subject to change. What I intended on stating is that you need to
learn the "intent" or the workings of the class! That should read "the "intent" or outer workings of the class

Jay

"Jay B. Harlow [MVP - Outlook]" <Ja************ @msn.com> wrote in message
news:%2******** *******@TK2MSFT NGP12.phx.gbl.. . Michael,
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.

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.
As for learning the inner workings of classes in the .NET Framework, I

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#" <xy*@yomomma.co m> wrote in message
news:eE******** *******@TK2MSFT NGP15.phx.gbl.. .
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".


Nov 21 '05 #117
Michael,
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 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#" <xy*@abcdef.com > wrote in message
news:U8******** *******@fe10.lg a...
"David" <df*****@woofix .local.dom> wrote in message
news:slrnd3ubju .fa.df*****@woo fix.local.dom.. .
On 2005-03-22, Michael C# <xy*@abcdef.com > wrote:
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?


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.


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


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.


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


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


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.

Nov 21 '05 #118
Cor,
That section of code is explained here:

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

Hope this helps
Jay

"Cor Ligthert" <no************ @planet.nl> wrote in message
news:Oj******** ******@tk2msftn gp13.phx.gbl...
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.


Nov 21 '05 #119

"Scott M." <s-***@nospam.nosp am> wrote in message
news:Ov******** ******@TK2MSFTN GP10.phx.gbl...
"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.
Uh, well, if in your book can=false, then ok.


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


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".
Nov 21 '05 #120

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.