Re: Dispose then set to nothing
- From: "Herfried K. Wagner [MVP]" <hirf-spam-me-here@xxxxxx>
- Date: Thu, 1 Mar 2007 03:32:50 +0100
"Göran Andersson" <guffa@xxxxxxxxx> schrieb:
Did I talk somewhere about resources. That effect I know, for the rest I see two writers in this thread who mix completely up the finalizing with disposing and have build their own mythe about that.
'IDisposable.Dispose' is all about releasing (unmanaged) resources. Well, and I do not agree with Goran's advice because I believe this is a micro-optimization. 'IDisposable.Dispose' is not intended as a mechanism to support deterministic finalization.
What is your opinion that it's intended for, then?
Releasing (primarily) unmanaged resources.
Yes, that is what you usually do when finalizing an object. As it's you who trigger the process, and not the garbage collector, makes it deterministic.
That's true. However, using 'IDisposable' makes perfect sense because the unmanaged resources are not under the control of the GC and may be limited.
They think that using low memory has advantages. Probably they use a computer with more than 2Gb computer while I am doing fine with my 512Kb without all those things they are telling.
I agree. However, I think that 'IDisplosable.Dispose' may also be used with managed resources such as very huge in-memory arrays which are stored inside certain objects. Take an 1 GB array holding a dictionary in a certain language, for example. When it's not used any more, it's IMO suitable to implement 'IDisposable' and let 'Dispose' erase the array.
There is no reason to dereference managed resources. If an object contains a large managed structure, just let the object go out of scope
Well, that's not always possible. Imagine the object can still be reached which prevents finalization by the garbage collector.
Yes, if you are going to hold on to the object long after it's unusable, then of course it won't work that way, but why would you do that?
Maybe it's not done in the code I have written. Normally I do not keep track where objects are referenced because this would make maintenance and extension of code more complicated.
Just remove the reference to the object, and it all goes away.
As I said, that's not always possible.
Going through the work of dereferncing child objects is totally wasted, as just letting go of the object does that for you automatically.
The GC cannot always do it automatically because it thinks the object is still used (which it is, but it's actually not needed any more).
Yes, it can always do that automatically.
Only if the object cannot be reached by the program any more, which may require removal of references a certain piece of code is not aware of.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>
.
- Follow-Ups:
- Re: Dispose then set to nothing
- From: Brian Gideon
- Re: Dispose then set to nothing
- References:
- Re: Dispose then set to nothing
- From: Herfried K. Wagner [MVP]
- Re: Dispose then set to nothing
- From: Göran Andersson
- Re: Dispose then set to nothing
- Prev by Date: Re: Dispose then set to nothing
- Next by Date: How to set value of SecureString?
- Previous by thread: Re: Dispose then set to nothing
- Next by thread: Re: Dispose then set to nothing
- Index(es):
Relevant Pages
|
