|
| When should I implement IDispose? |
|
|
|
|
| Messages |
|
Related Types |
This message was discovered on microsoft.public.dotnet.general.
Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions.
| Gabriel |
I have several custom classes in my app that have a definite lifetime. During the course of runtime, there will be a few thousand of these objects allocated. The objects have a definite lifetime: they will be used until the user intervenes, at which point they should be deleted from memory.
Given that these thousands of objects all have a definite lifetime, and yet, they do NOT have any unmanaged resources or data streams, should I implement IDisposable? If so, should I null out all reference types in the .Dispose method? The Java programmer in me says yes, but I'm unsure if and when I should implement IDisposable.
|
|
|
| |
|
| |
| |
| Jon Skeet [C# MVP] (VIP) |
Gabriel <Click here to reveal e-mail address> wrote:
[Original message clipped]
And at that point will they still be referenced?
[Original message clipped]
The Java programmer in you is wrong, both in Java and C#.
If you've got no unmanaged resources, nor any references to other
objects which need disposing, then you almost certainly don't want a
Dispose method.
Depending on your exact situation, you may want to null out some
references *to* your objects if they're in variables which are still
"live", but again that's rarely necessary.
--
Jon Skeet - <Click here to reveal e-mail address>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
|
|
|
| |
|
|
| |
|
| |
| Cor |
Hi Garbriel,
If it are big objects, let say tif images, I definatly would do that.
Otherwise I would wait to see what it did mean.
My thinking is always, why should the program make a trip to the
operatingsystem to do the disposing, while there is still memory enough?
Let it be done in a nice garbage sweep.
But just my thought,
Cor
|
|
|
| |
|
|
| |
| |
| Jon Skeet [C# MVP] (VIP) |
Cor <Click here to reveal e-mail address> wrote:
[Original message clipped]
Memory is only one resource though - handles are somewhat different.
It's not a good idea to have handles open for longer than you need to,
as "pressure" on the number of available handles won't cause the
garbage collector to fire in the same way that pressure on memory will:
instead, programs will just fail.
--
Jon Skeet - <Click here to reveal e-mail address>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
|
|
|
| |
|
|
| |
| |
| Cor |
Hi Jon,
> It's not a good idea to have handles open for longer than you need to.
Thanks,
Can you explain why not.
Cor
|
|
|
| |
|
| |
| |
| Jon Skeet [C# MVP] (VIP) |
Cor <Click here to reveal e-mail address> wrote:
[Original message clipped]
Um, I did in the rest of the post. Handles are a limited system
resource, basically.
--
Jon Skeet - <Click here to reveal e-mail address>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
|
|
|
| |
|
|
| |
| |
| Cor |
Hi Jon,
[Original message clipped]
I did not see that, I saw that you told it would not force the the garbagde
collector to start if it where in your opinion to much, but you did not tell
why it was not a good idea to have handles open for longer than you need
to, as you wrote.
Cor
|
|
|
| |
|
| |
| |
| AnonymousHoward |
A handle is a way to open and close system resources. Resources can be
graphic objects, files, mutexes, etc. They take up system space like memory
for example. The resource the handle points to does not influence the
garbage collector.
"Cor" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Cor |
Hi Howard,
[Original message clipped]
But if there is still 16Gb memory free, is that than important?
That was the question.
Cor
|
|
|
| |
|
|
| |
| |
| AnonymousHoward |
[Original message clipped]
I don't see where anyone said there is any amount of memory free or
available. Maybe I missed it?
What I did see is Gabriel's statement "The objects have a definite lifetime:
they will be used until the user intervenes, at which point they should be
deleted from memory."
If he had handles to operating system resources, and he wanted those
resources reclaimed when the user intervenes then yes implement IDispose,
those resources would reclaimed then and not when the garbage collector gets
around to it. If there are no handles to operating system resources then I
would say no let the garbage collector do it.
"Cor" <Click here to reveal e-mail address> wrote in message
news:eaDn$Click here to reveal e-mail address...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Lloyd Sheen |
Ok, I don't understand how implementing the IDisposable does anything.
I have an object. I create it and then set the reference to nothing. I
have a dummy line for debugging in the finalize and Dispose subs but until I
close the app neither is called. When I close the app the Finalize is
called but the Dispose is never called.
So basically we are at the wim of the GC.
Lloyd Sheen
"AnonymousHoward" <Click here to reveal e-mail address> wrote in message
news:sis3c.221833$jk2.786980@attbi_s53...
[Original message clipped]
|
|
|
| |
|
| |
| |
| AnonymousHoward |
It has to be called explicity or the object in question can be used within
the using statement in which dispose would be called automatically. Its not
fool proof because developers forget or don't realize they should be calling
it, but it is a way for cleaning up resources in a deterministic way that
are not collected by the garbage collector.
"Lloyd Sheen" <Click here to reveal e-mail address> wrote in message
news:Pit3c.218381$Click here to reveal e-mail address...
[Original message clipped]
|
|
|
| |
|
|
| |
| |
| Lloyd Sheen |
Ok, a question then.
We had in VB6 a class called WaitCursor. When an operation would take a
long time at the beginning of a subroutine create an instance of WaitCursor.
This would change the cursor to a wait cursor (there are more details but
not important).
When the variable would go out of scope the Terminate would be called and
the Object would figure out what to do. Now this is broken. I think that
all Dispose is a common name to call. Since the developer must call it, and
that can be missed there seems to be no way in the framework to take
advantage of the Constructor/Destructor pattern for objects.
Lloyd Sheen
"AnonymousHoward" <Click here to reveal e-mail address> wrote in message
news:Cpt3c.92590$PR3.1500983@attbi_s03...
[Original message clipped]
|
|
|
| |
|
| |
| |
| AnonymousHoward |
> I think that all Dispose is a common name to call. Since the developer
must call it, and
[Original message clipped]
Thats the way I see it too.
> Now this is broken.
Well I come from a C++ background, if an object was created with a new and
went out of scope without a delete, that was a memory leak. Even with COM
you had to make sure you decremented your object's reference count to
prevent memory leaks. While there were helper classes for both these
situations it still happened. So from my point of view nothing is broken.
Its just a different memory bookkeeping model. I consider it better but you
are still forced to know whats going on in the CLR to make things efficient.
If you are coming from a VB background you may not see it this way and I
understand why.
"Lloyd Sheen" <Click here to reveal e-mail address> wrote in message
news:rwt3c.218660$Click here to reveal e-mail address...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Cor |
Hi Howard,
[Original message clipped]
What is that what you understand, I am curious what you mean with the
sentence above?
In my opinion it looks if you are making the often made fault from people
making programs, who have a small scoop on the different OS that are/have
been and programming languages.
They think often that solutions for failures in one programming language or
OS are universal solutions for all failures.
One of the purposes from managed code (I am only talking about managed code)
is to overcome those failures and prevent by instance memory leaks.
And therefore my question again, why do you want to manage the managing code
by hand, what is the advantage?
Cor
|
|
|
| |
|
|
| |
| |
| AnonymousHoward |
[Original message clipped]
VB had a more deterministic way of cleaning up resources. I believe it has
reference counting. I'm not saying its better or worse, reference counting
has its problems too. I'm saying when all references to an object went away,
the object was cleaned up. I believe this is what Lloyd was complaining
about. Garbage collection on the other hand, the object is cleaned up when
the garbage collector gets around to it.
[Original message clipped]
I have built real-time and enterprise solutions in Unix/Windows/Linux with
C,C++,Perl,Java,VB and now C#/VB.NET.
> And therefore my question again, why do you want to manage the managing
code
> by hand, what is the advantage?
Where do I say I want do that? I don't say that and I don't want to do that.
Just because the garbage collector takes care of most of the memory
problems, it does not take care of ALL the problems. Look around the message
boards, people complain about memory consumption all the time, its one of
the main complaints. There have been gazillion articles on understanding the
CLR, garbage collection, and memory consumption, along with best programming
practices. Many by MS insiders and experts. Memory consumption is an issue,
there things you should and should not do.
Example, when you get a .NET graphics object, it is a managed object, but
what should be the first thing you do with it when you are done with it. You
should call Dispose to release the underlying OS resources, in no way should
you let the garbage collector control the destruction of these resources,
this documented and suggested by MS themselves. Why? Because a managed
object could have a single handle property that points to a gigabyte sized
OS resource. What does the garbage collector see as the size of the object?
Ignoring the CLR overhead for the object itself, it thinks the size of the
object is 32 bits (or 64 if running on the 64 bit system). Will the garbage
collector be in a hurry to destroy this object? No, but in the meantime 1
gig of your memory is consumed by this dead object. Graphics object is not
the only "managed" object that has handles to OS resources.
"Cor" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Cor |
[Original message clipped]
VB.net, C#, J++ and C++ with managed code are almost completly equal when
they are compiled. In this newsgroup are that the only languages which
counts and where we are talking about.
I find it an efficient way and that is what I am talking about not to make
everytime a roundtrip to the OS to clean up resources if there is enough
memory.
[Original message clipped]
Never seen that in this newsgroup seriously, what I have seen is that the
taskmanager shows a lot (but what is a lot) of memory consumption and that
people are afraid if the GC does work correct because it does start
immidiatly when the program closes, but I cannot be sure of that of course.
[Original message clipped]
The graphics object is one of those where Microsoft explicitly advices to
dispose. When you see the start of this thread you will see that I did
mention the image as to dispose.
Cor
|
|
|
| |
|
| |
| |
| Jon Skeet [C# MVP] (VIP) |
Cor <Click here to reveal e-mail address> wrote:
[Original message clipped]
That's *really* not a good idea, IMO. If something implements
IDisposable, that's a sign saying that you should call Dispose when
you're finished with it (if you're responsible for its lifetime).
Guessing as to which classes are really just taking memory and which
are taking other system resources (such as handles) is likely to cause
you problems in the future.
[Original message clipped]
Anything which implements IDisposable is pretty much explicitly
advising you to dispose of it properly, in my view.
--
Jon Skeet - <Click here to reveal e-mail address>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
|
|
|
| |
|
|
| |
| |
| Cor |
Hi Jon,
This thread becomes to long, it is not necessary to answer , the change that
we will agree is very low. (But that we did know already)
:-)
Cor
|
|
|
| |
|
| |
| |
| AnonymousHoward |
> This thread becomes to long, it is not necessary to answer , the change
that
> we will agree is very low. (But that we did know already)
While I know this is true, unfortunately agreement is not my goal. I believe
you gave the original poster bad advice with out knowing the specifics,
which in turn could hurt him and his development effort.
"Cor" <Click here to reveal e-mail address> wrote in message
news:O7$Click here to reveal e-mail address...
[Original message clipped]
|
|
|
| |
|
| |
|
|
| |
| Cor |
Hi Jon,
[Original message clipped]
Why?
That there is VB.net does not mean that everybody is explictly advised to
use it.
Cor
|
|
|
| |
|
|
| |
| |
| Jon Skeet [C# MVP] (VIP) |
Cor <Click here to reveal e-mail address> wrote:
[Original message clipped]
If something wasn't encouraging its explicit disposal, why would it
implement IDisposable in the first place?
--
Jon Skeet - <Click here to reveal e-mail address>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
|
|
|
| |
|
|
| |
| |
| Lloyd Sheen |
Ok again what I am talking about is the loss of a fundamental programming
idea.
When an object goes out of scope and is no longer usable it should destruct.
This give the developer the abiltity to catch this an do whatever is
required. It seems that the USING will be a new addition to the VB language
in the next release so MS realizes thru the many complaints that there were
many developers using this feature.
It the point at which this happens is when ever the framework decides then
the developer is left to the wim of that framework. IDispose is a good
option to allow developers to do the same but if forgotten it is better that
the destructor is called when the object goes out of scope.
Lloyd
"Jon Skeet [C# MVP]" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]
|
|
|
| |
|
| |
| |
| Jon Skeet [C# MVP] (VIP) |
Lloyd Sheen <Click here to reveal e-mail address> wrote:
[Original message clipped]
That's a problem to start with in a managed world, as an *object* never
goes out of scope - only a *variable* does. Working out whether or not
the variable going out of scope means that the object is no longer
referenced is a very expensive operation.
There was a very good article on this somewhere, explaining just why it
was impossible to get deterministic finalization without huge other
penalties, but I can't find it now. I'll post a reply to this message
if I find it.
--
Jon Skeet - <Click here to reveal e-mail address>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
|
|
|
| |
|
|
| |
| | |
|
|
|
| |
| Lloyd Sheen |
What I was complaining about was the fact that there are lots of programs
that have relied on the fact that when an object goes out of scope the
destructor is called. In the destructor the code looks after releasing
resources or whatever should happen when the object is not required any
more.
This is not the case in DOT.NET. Now you have to implement IDisposable and
remember to call the Dispose of the object. For routines that have multiple
exit points this becomes a problem. The developer would have to remember (a
big cause of problems) to dispose the object and finding the code that does
not do that during debugging can be a tedious and time consuming exercise.
How you code to a standard that says that something will eventually happen
is poor design in my mind. The whole purpose of coding is to provide a
consistant processing path.
Lloyd Sheen
"Cor" <Click here to reveal e-mail address> wrote in message
news:%Click here to reveal e-mail address...
[Original message clipped]
|
|
|
| |
|
| |
| | |
|
|
|
| |
| Cor |
garbage collector does "not" start when the program .........
|
|
|
| |
|
| |
|
| |
| AnonymousHoward |
[Original message clipped]
Lloyd was complaining about and comparing the newer .NET languages with the
older VB environment. So it is relevant to his message. Also...
[Original message clipped]
Now you confuse me, if you didn't want to talk about VB why did you ask me
to respond to my VB statement????
[Original message clipped]
You keep assuming there is enough memory without knowing the specifics. I
don't program with that assumption. That is dangerous.
The original poster never mentioned memory availability, installation
environments, number of applications running on the machine, number of
instances of his specific application, number of user, type of application,
etc.. He said thousands of objects that should be cleaned up when the user
intervenes.
Thousands of objects can hog up just as much resources as one big one. For
example, if he is talking about a single web server application with
mutliple sessions, then one could multiply that by every user logged on. I'm
assuming worse case here but even if it was a single application but the
machine wasn't equipped to handle thousand of objects with small graphic
images he should be equipped now to call dispose on them. Its better to be
safe than sorry when working with incomplete specs. Thousands of small
managed images,files,graphics,etc. should have disposed called for them just
as importantly as one large one. Just assuming the GC will work OK without
knowing the specifics is wrong.
[Original message clipped]
Look at the .NET performance newsgroup. Usually the first thing that is
suggested when memory leak "thought" to have happen is IDispose of graphic
objects, file objects, etc.. I just went over and sure enought there was
one.
"Cor" <Click here to reveal e-mail address> wrote in message
news:#f5tk$Click here to reveal e-mail address...
> > VB had a more deterministic way of cleaning up resources. I believe it
has
> > reference counting. I'm not saying its better or worse, reference
counting
[Original message clipped]
|
|
|
| |
|
| |
| |
| Cor |
Hi Anonymous,
What are you doing, you quote your text as if it was mine, why you do that?
Cor
|
|
|
| |
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
BootFX
Reliable and powerful .NET application framework. |
|
|
|
|
|
|
