Dispose Method

  • Thread starter Thread starter Dave
  • Start date Start date
D

Dave

Could someone explain to me when it is appropriate to call the Dispose()
method that is contained in most .Net Framework Objects.

The MSDN says that Dispose:

Releases all resources used by the Object

and or

Releases the unmanaged resources used by the Object and optionally releases
the managed resources.

So if I'm cleaning up an object do I need to call Dispose prior to it going
out of scope ?

Any Thoughts ?
 
Always.

Most objects in the framework aren't disposable. Those that are, should
be disposed before they are dereferenced or go out of scope.

Only objects that uses unmanaged resources (or contains objects that do)
are disposable. These need to be disposed so that they can release the
resources.

There are of course special cases where an object actually doesn't need
to be disposed, because it for some reason never allocated any unmanaged
resources or already has released them, but knowing what those special
cases are takes a lot of knowledge about every specific class. So, if it
has a Dispose method, just call it and be safe.

Calling the Dispose method never hurts. By definition the Dispose method
can be called any number of times without problem.
 
Dave,

Can you show me where the first one beneath is written.

\> The MSDN says that Dispose:
Releases all resources used by the Object
Click to expand...
Releases the unmanaged resources used by the Object and optionally
releases
the managed resources.
Click to expand...

The one above is the corect one. Be aware that the dispose method is
overloadable.
So if I'm cleaning up an object do I need to call Dispose prior to it
going out of scope ?
Click to expand...

No only those which contains unmaneged resources and that are less than you
think. You can as well have overloaded a methode and than you can use the
dispose to overload that with the releasing from the by you used unmanaged
resources.

Adviced to dispose are modal dialogs, pens, bitmaps, real streams.

Cor
 
Goran,
Most objects in the framework aren't disposable. Those that are, should be
disposed before they are dereferenced or go out of scope.
Click to expand...
You don't write it, however 80% of the most used objects have the method
dispose.
That is just because they inherit from component model. In real figurs it is
still 20% of the classes.

This is the same as that 100% of the objects have the method GetHashCode,
that a method is in every object is in my opinion no reason to use that
forever.

Just my thought reading your message.

Cor
 
Note response below


Cor Ligthert said:
Dave,

Can you show me where the first one beneath is written.
Click to expand...

I took these definitions from the Dispose method on the Graphics object in
the MSDN knowledge base. I really only used the graphics object as an
example.

\> The MSDN says that Dispose:


The one above is the corect one. Be aware that the dispose method is
overloadable.


No only those which contains unmaneged resources and that are less than you
think. You can as well have overloaded a methode and than you can use the
dispose to overload that with the releasing from the by you used unmanaged
resources.

Adviced to dispose are modal dialogs, pens, bitmaps, real streams.
Click to expand...


How should know whether to call this ? Should I just call it because it's
there ?
 
Dave,

How should know whether to call this ? Should I just call it because it's
there ?
Click to expand...
In my opinion not, moreover mostly if you use a component or a form to
create your class than there is an Idisposable methode in it. Because that
the pens etc. use a lot of handles, it is adviced to speed it up. However in
computing is nothing for free, handling dispose means forever time. While
normally it is done using the managed methods as soon as it is needed. The
reason it is called managed code is that it is to take care of the releasing
of objects for you.

There is endless written with system.data (ADONET) to use forever dispose.
There is in that namespace AFAIK not any unmanaged resource.

The same we see people telling that dispose is not for nothign so use is. Do
you use every method forever in every class?

Cor
 
Cor said:
Goran,

You don't write it, however 80% of the most used objects have the method
dispose.
Click to expand...

That depends on how you use the framework...
That is just because they inherit from component model. In real figurs it is
still 20% of the classes.
Click to expand...

But they are used in the component model, so that takes care of the
disposal.
This is the same as that 100% of the objects have the method GetHashCode,
that a method is in every object is in my opinion no reason to use that
forever.
Click to expand...

That is a completely different thing. The GetHashCode method has nothing
to do with the lifecycle of an object.

Most classes have a constructor, and you need to use the constructor to
create an object, there is no alternative. It's the same when you
dispose of the object. Calling the Dispose method is the correct way to
do it. There is no alternative.
 
Goran,

Most classes have a constructor, and you need to use the constructor to
create an object, there is no alternative. It's the same when you dispose
of the object. Calling the Dispose method is the correct way to do it.
There is no alternative.
Click to expand...

The dispose method is not the Finalize method as a lot of people want to
think.

The finalizing is done by the framework, exactly why it is called managed
code.

Cor
 
Cor said:
Goran,



The dispose method is not the Finalize method as a lot of people want to
think.
Click to expand...

That is exactly why you have to call the Dispose method. If it could be
done by the finalizer, there wouldn't be any Dispose method at all.
The finalizing is done by the framework, exactly why it is called managed
code.
Click to expand...

Yes, in some cases the finalizer can handle the disposal of the object
also, but it's not efficient.

When the garbage collector finds an object that can be garbage
collected, but has a finalizer defined, it will call the finalizer,
which in turn will call the Dispose method. When the garbage collector
comes around the second time it can finally collect the object.

If you call the Dispose method yourself, the garbage collector doesn't
call the finalizer, and the object can be collected on the first run.
 
The same we see people telling that dispose is not for nothign so use is. Do
you use every method forever in every class?
Click to expand...

Of course we don't use all the methods of a class just because they're
there. That would be insane. But most methods of the class are to do with it
as an object - and Dispose() is different - because it's about managing the
resources the object consumes that the GC cannot/does not collect.

Cor says that the majority of objects inherit from the component model and
so get a Dispose() "for free" but don't actually need it.

Maybe so - but do we really know what is going on inside any object we
haven't written? In my opinion - no, we don't; I'd rather do defensive
programming and ensure that Dispose is called if its there.

That doesn't mean, necessarily, that I must explicitly call it. If the
object was added to my class by the designer, then I can trust that the
designer hooked up its Dispose. If I have written my own Dispose I should
call the Dispose on all the objects I allocate and reference as member
variables from within that method.

That leaves only objects, like Graphics, or Fonts, etc. that I allocate
within a function and whose scope is limited to that function. On these
objects I MUST call dispose before they go out of scope since there is no
other path for their dispose to be called

So the question remains: if an object exposes Dispose() when is it safe NOT
to call it? The corollary is: if an object exposes Dispose() can we assume
that there is a reason for it - i.e. that the object needs to be disposed or
the resource it represents will leak?

Since Dispose is about releasing memory (and resources) used by unmanaged
objects the GC WILL NOT do anything to clean them up - exactly because they
are unmanaged. So for such objects we MUST call Dispose to prevent leaks.

Also note - if you want to use Finalize to call Dispose for you for member
objects that must be disposed, remember that you need to write your Finalize
(the system can't do it for you!).

Chris
 
Cor Ligthert said:
The dispose method is not the Finalize method as a lot of people want to
think.

The finalizing is done by the framework, exactly why it is called managed
code.
Click to expand...

Finalizing is like a safety net. It tries to catch programming errors
where people forgot to use Dispose, but it shouldn't be relied upon too
heavily because the GC is a memory manager, not a resource manager.

-- Barry
 
Could someone explain to me when it is appropriate to call the Dispose()
method that is contained in most .Net Framework Objects.
Click to expand...

Here is a very simple rule to follow when it comes to IDisposable objects
that will make sure that you're always on the safe side (it's actually
similar in some way to the delete rule in C++):

1) If you are using a IDisposable object as a local variable in one of your
method, call its Dispose() method as soon as you don't need it anymore
(unless of course you're giving it to another class that will use it as a
member variable). If the code of your method can raise exceptions then it
should be placed in a catch / finally block so that you can dispose the
IDisposable objects in the finally block. Alternativaly, you can use the
using{} construct.

2) If your class has a member variable of a type that implements
IDisposable, then your class itself should implement IDisposable (and
implement it properly, see the doc for the IDisposable interface for an
example). In your class's Dispose() method, call the Dispose() method all
all its IDisposable member variables. Of course, your class now being an
IDisposable class, it should be treated as such.

Note that alling Dispose() can in some cases take time. For example, if
you've implemented a custom control that does a lot of drawing always using
the same Brush and the same Font, instead of creating them and disposing
them every time the OnPaint method is called, it might be a better idea to
store them as member variables so that they can be reused and dispose them
only in the Dispose() method of your control.
 
Cor Ligthert said:
You don't write it, however 80% of the most used objects have the method
dispose.
That is just because they inherit from component model. In real figurs it is
still 20% of the classes.
Click to expand...

It's closer to 12%. For the public types in these assemblies in v2.0:

mscorlib, System, System.Configuration.Install,
System.Data.OracleClient, System.Data.SqlXml, System.Data,
System.Deployment, System.Design, System.DirectoryServices.Protocols,
System.DirectoryServices, System.Drawing.Design, System.Drawing,
System.EnterpriseServices, System.Management, System.Messaging,
System.Runtime.Remoting, System.Runtime.Serialization.Formatters.Soap,
System.Security, System.ServiceProcess, System.Transactions,
System.Web.Mobile, System.Web.RegularExpressions, System.Web.Services,
System.Web, System.Windows.Forms, System.XML, System.Configuration,

These are the statistics:

Public types: 6359
Have public Dispose(): 697
Assignable to IDisposable: 775

-- Barry
 
Cor Ligthert said:
There is endless written with system.data (ADONET) to use forever dispose.
There is in that namespace AFAIK not any unmanaged resource.

The same we see people telling that dispose is not for nothign so use is. Do
you use every method forever in every class?
Click to expand...

Finalize() (C# destructor) is one thing - that's something you only ever
need on a class that *directly* encapsulates an unmanaged resource.

And of course it makes sense to call Dispose() on classes which also
implement a Finalize() method, because that way you get explicit and
immediate release of the unmanaged resource.

If a class logically owns (via a private reference) an object which
implements Finalize(), it thus stands to reason that it should call
Dispose() on this private reference so that the resource can be
deallocated - because GC isn't a resource manager, it's a memory
manager.

So how can it dispose of these inner references to finalizable objects?
It supports IDisposable and exposes a Dispose() or Close() method.

This is the reason that it is important to always call Dispose() or
Close() when it is available:

1) Because GC is not a resource manager,
2) and the only way to release resources that you (as a client of the
class) *cannot* *see* (and shouldn't even be aware of, by implementation
hiding) is by calling Dispose() or Close().

I think it's irresponsible to say that you don't need to call Dispose()
on types which you don't think represent unmanaged resources.

-- Barry
 
Back
Top