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  5383 
On 2005-03-22, Scott M. <s-***@nospam.nospam> wrote: 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.
Well, actually you didn't say that the first time,
Okay, let's see what I actually said...
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.
That's pretty straightforward. Some objects need runtime disposing, but
there's a lot of objects that don't, even if those objects might need
design-time disposing.
Originally you disagreed that this was even possible. Do you still hold
that opinion?
you said: 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?).
What I got from this was you saying "you don't need to dispose web form
controls at run-time". And this is not true. As you say an OleDb
connection object at run-time will be holding on to unmanaged resources that
do not have anything to do with GDI and so this connection object should be
disposed at run-time.
An OleDbConnection isn't a web control.
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.
And, gee, your sarcasm is something we can do without as well.
Perhaps you're right.
Do you
disagree that OleDb connections hold unmanaged resources? What part of
saying that an OleDb connection needs to be disposed at run-time do you
disagree with?
Short answer: yes, you should dispose an OleDbConnection at runtime.*
* Longer answer, OleDbConnection is one of the most complex examples
there is. The problem is the subtle differences between Close and
Dispose on an OleDbConnection, and also the effect that Dispose and
FreeCoTaskMem can have on the connection pool and the interface with the
actual DB provider. In truth, I honestly don't know the answer
(although profiling seems to imply that it really doesn't matter much
either way). Mind you, you should definitely *Close* an
OleDbConnection, but Close and Dispose aren't the same thing, despite
what a lot of the docs say.
On 2005-03-22, Michael C# <xy*@yomomma.com> wrote: OK Got it. Learn IL, then use Object Browser and Reflector to observe the
objects...
Well, I actually think everyone should know IL anyway :)
Y'Know, if someone would just write a book called ".NET Dispose() List" or
some such crap, with a complete listing of all built-in Framework classes
that require Dispose to be used, I'd be second in line to buy the damn
thing. I thought the .NET Framework was going to make life easier - but
sometimes it seems that old problems were just exchanged for their 21st
century equivalents.
Dispose is a tough problem, I'm not disagreeing there. Ideally we'd
have automatic ref counting systemwide and deterministic finalization,
but the technology just isn't there yet.
OTOH, Dispose just isn't something I spend my days worrying about
(unlike C++, for example, where dangling references and object lifetimes
were a constant concern). A few simple ground rules get me through the
common objects, and if I screw up a bit, I feel pretty confident that
most objects I deal with will implement the Finalize/Dispose pattern
properly so it won't really hurt too much.
There are things I can rail against if I choose (the component model was
a terrible idea, IMHO), but in general I think MS made the right
trade-off with the GC and Dispose.
>> [I am not aware of any complete text that lists the do's and don'ts of what
to dispose or not. Instead, I am aware that circumstance by
circumstance,
one can determine if a particular class should or shouldn't be disposed.]
Of course I can readily accept the fact that you do not know this
information; however, you must accept the fact that someone else may know,
or at least be aware of good resources for finding, this specific
information.
That's true. As someone who has worked with .NET since early beta, my
answer was based on what I have seen, heard and read. I believe that answer
to be correct. The list you seek does not exist. Up to you to do what you
want with that information, but it IS my answer to the specific question you
asked.
Ah but see, you didn't answer the question that "I was asking". See, I
didn't ask what you or other people eat, I asked for a complete list of
what is and isn't harmful to eat. So as soon as you get that list to me,
I'll get you the imaginary list you are looking for.
Ah, now perhaps you understand my frustration with your "answers" to my
question. Perhaps not.
Actually not since I did answer your direct question, you just don't wish to
acknowledge the answer. You, on the other hand, did not address my
question.
Like you, I didn't ask what you or other people Dispose, I asked for a
complete list of what should and should not be Disposed.
You know, I'd like you to tell me where my answer to your question was what
I personally Dispose or don't Dispose because you keep saying that I've
avoided your direct question and I keep telling you that this is not the
case. You and I have had 2 conversations going in this thread (1 about your
question and one about "splitting hairs" which is slightly off-topic). I
honestly believe that you have taken my posts about one and applied them as
responses to the other.
Which should make a much, much shorter list than items that can be
swallowed. After all, there are far more things that can be "swallowed"
than there are built-in classes in the .NET Framework that expose a
Dispose method; however, as you can see, your answers apply to this
situation (and probably any other situation you could possibly think up),
without losing any of their practical value.
The actual amount of items in the Framework are large enough and the
inheritance used to create them is intracate enough to make such a list an
improbability (if not an impossibility) which is the point of my analogy.
Now, if you want to get into more practical detail, we could look at all
objects that expose a "Swallow" method. We can further refine the "list"
to "you will learn what not to swallow by experience" (you will learn when
to use Dispose by experience),
Who said "you will learn when to use Dispose by experience"? That's not
what I said. I said "circumstance by circumstance,
one can determine if a particular class should or shouldn't be disposed"
"you can teach yourself advanced Chemistry and Biology courses and perform
chemical analysis on everything that has a Swallow method" (after all you
can learn IL and use ILDASM and Object Browser to determine which objects
to Dispose), you can follow the Manufacturer's Recommendations for
Swallowing - assuming there are any, and make note of the exceptions. I
can also tell you that it is correct to swallow chocolate milk and chicken
casserole based on their Swallow interfaces. That's 2 down, how many to
go?
Ah bravo! Now, you've finally got to the point. YES, what you have written
above IS the course one should take to know when to and when not to Dispose.
And so, the last thing I will say here (and leave you whatever last words
you like) is that with this last paragraph you have (wittingly or not and
like it or not) arrived at what I've been trying to tell you all along.
This is the answer to your question: there is no list! Use ILDASM, the
Object Browser, and whatever other tools available to investigate the
classes you work with and learn about them. Then, based on what you've
learned, you can make a much more informed decision about Dispose.
Good luck to you.
At this point, it is probably best that we just agree to disagree and go our
separate ways. And here I suppose I get the last word in, and my last word
is: Thank you.
Jay,
I did first your routine and than the way I normal do it, I did not push the
F11 enough, than I would have seen it.
Thanks,
Cor
Michael, It would seem the next step would be to determine if the Dispose and
Disposable types use unmanaged resources. Do you think there is a
programmatic way to determine this?
Not really. However it might not provide you with what you want any way!
One Pattern/Recommendation (don't have the link handy, I can find it if you
like) is for your public class to define a private inner (nested) class that
contains (only manages) the unmanaged resource. Both classes Implement
IDisposable, however only the inner class implements Finalize. The public's
class Dispose delegates Dispose to an instance of the inner class.
This way only the small dedicated class is finalized, where as the bulkier
outer class will GC quicker. Normally this pattern would be used where you
have a class with a lot of managed instance fields, and only a single
unmanaged instance field.
Based on this thread I am revising my "rules" for when I don't call Dispose,
thus simplifying when I do call it. However! I have not flushed out the
entire list yet. When I get the list flushed out I will post it here. Note
it will be a list of rules similar to David's list (I believe it was
David's). Unfortunately it will not be a list by type! As I see little value
over time with a list by type! However if you accept the rules then creating
a list by type should be easy enough.
Hope this helps
Jay
"Michael C#" <xy*@abcdef.com> wrote in message
news:rH****************@fe10.lga... Now *that* is an excellent tool to discover a baseline. Thank you.
IMHO, MS just needs to dedicate a person or two to documenting this and
letting people know when and how to use their product; rather than leaving
it to people to accidentally discover, or spend hours researching this
when they could be doing far more productive things. It would seem the
next step would be to determine if the Dispose and Disposable types use
unmanaged resources. Do you think there is a programmatic way to
determine this?
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:eZ**************@tk2msftngp13.phx.gbl... Michael,
Using the following in a VS.NET 2003 Windows Forms application I get:
Assemblies: 5
Types: 3384
Disposable: 226
Dispose: 132
There are significantly more then 5 assemblies in the entire .NET
Framework...
Const bindingAttr As BindingFlags = BindingFlags.DeclaredOnly _
Or BindingFlags.Instance Or BindingFlags.IgnoreCase _
Or BindingFlags.Public Or BindingFlags.NonPublic
Dim disposable As Type = GetType(IDisposable)
Dim countAssemblies As Integer
Dim countTypes As Integer
Dim countDisposable As Integer
Dim countDispose As Integer
For Each a As [Assembly] In
AppDomain.CurrentDomain.GetAssemblies()
countAssemblies += 1
For Each t As Type In a.GetTypes()
countTypes += 1
If disposable.IsAssignableFrom(t) Then
Debug.WriteLine(t.FullName, "IDisposable")
countDisposable += 1
End If
Try
If t.GetMethod("Dispose", bindingAttr) Is Nothing Then
' No Dispose method.
Else
Debug.WriteLine(t.FullName, "Dispose")
countDispose += 1
End If
Catch ex As AmbiguousMatchException
Debug.WriteLine(t.FullName, "Dispose(s)")
countDispose += 1
End Try
Next
Next
Debug.WriteLine(countAssemblies, "Assemblies")
Debug.WriteLine(countTypes, "Types")
Debug.WriteLine(countDisposable, "Disposable")
Debug.WriteLine(countDispose, "Dispose")
NOTE: The "t.GetMethod" is an attempt to see if there is any Dispose
method declared on the type itself, as oppose to simply inheriting the
method from a base class...
Hope this helps
Jay
"Michael C#" <xy*@yomomma.com> wrote in message
news:Ou**************@TK2MSFTNGP12.phx.gbl... Ahh, one down, 85 times X variations to go :) It seems like there are a
lot more than 85 classes, however. But then again, I might be counting
classes that are automatically excluded by virtue of not implementing
Dispose() anyway.
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in
message news:OH**************@TK2MSFTNGP09.phx.gbl...
Michael,
> See, now we're making progress. Two down.
I would consider it one type, that is System.Windows.Forms.Form.
Consider a variation of the sample:
Dim dialog As Form
dialog = New OptionsDialog
dialog.ShowDialog()
dialog.Dispose()
dialog = New OptionsDialog
dialog.Show()
Its the exact same form, however based on how it is shown
(Form.ShowDialog or Form.Show) changes if Dispose is needed or not...
> Now how many classes does that leave? :)
The following page suggests there are 85 classes. I'm not sure if that
only includes types directly implementing IDisposable or if it includes
types that inherit IDisposable from a base class also.
http://www.vbinfozine.com/a_disposable.shtml
I think the rule that is tripping people up (including the way I have
stated things) is when IDisposable is in a base class (such as
Component).
Hope this helps
Jay
"Michael C#" <xy*@yomomma.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
> "Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in
> message news:%2****************@TK2MSFTNGP15.phx.gbl...
>> Consider objects that inherit from System.Windows.Forms.Form:
>>
>> Dim dialog As New OptionsDialog ' inherits Form
>> dialog.ShowDialog()
>> dialog.Dispose()
>>
>> Dim child As New MidChildForm ' inherits Form
>> child.Show()
>
> See, now we're making progress. Two down. Now how many classes does
> that leave? :)
>
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> wrote in message
news:uR**************@TK2MSFTNGP15.phx.gbl... Michael, It would seem the next step would be to determine if the Dispose and
Disposable types use unmanaged resources. Do you think there is a
programmatic way to determine this? Not really. However it might not provide you with what you want any way!
One Pattern/Recommendation (don't have the link handy, I can find it if
you like) is for your public class to define a private inner (nested)
class that contains (only manages) the unmanaged resource. Both classes
Implement IDisposable, however only the inner class implements Finalize.
The public's class Dispose delegates Dispose to an instance of the inner
class.
This way only the small dedicated class is finalized, where as the bulkier
outer class will GC quicker. Normally this pattern would be used where you
have a class with a lot of managed instance fields, and only a single
unmanaged instance field.
Ugh. So the unmanaged resources could be hidden from prying eyes anyway?
Too bad there's not a public read-only Boolean attribute you could check to
see if an object *needs* to be Disposed of or not. Something like
".DisposeRequired" or some such, or even a flag indicating that it uses (or
might use) unmanaged resources to give you a better idea up front that yes
this should be Disposed.
I really don't like this idea of writing sub-optimal code until I encounter
a problem and realize that 'hey I should have Disposed of that', then fixing
it after the fact with a "service pack"-type remedy. I am taking the plunge
and learning IL (it can't be harder than x86 Assembler can it?) I don't
mind learning something new, but I don't like feeling like I'm being forced
to learn it by weaknesses in my chosen platform - or even worse - by
weaknesses in the documentation of my chosen platform.
Based on this thread I am revising my "rules" for when I don't call
Dispose, thus simplifying when I do call it. However! I have not flushed
out the entire list yet. When I get the list flushed out I will post it
here. Note it will be a list of rules similar to David's list (I believe
it was David's). Unfortunately it will not be a list by type! As I see
little value over time with a list by type! However if you accept the
rules then creating a list by type should be easy enough.
I have no problem accepting the rules, if they help me narrow down the focus
of the problem. Throwing out things like "'Appropriately' use Dispose" in
answer to the question of "How do I Appropriately use Dispose?" is basically
throwing the question back in the asker's face, and doesn't really narrow
the focus of the problem.
Thanks for your help on this! This thread has been closed and replies have been disabled. Please start a new discussion. |
