0

I have a function wherein i have created an object for a class, to use it inside the function and return it to the calling funciton.

Myobj read(string s)
{
   Myobj obj = new Myobj ();
   ..................
   ........................
    return obj
 }

In this case should i mandatorily dispose the object i have created.

Also when should i use destructor,dispose , finalize

user3048305
  • 23
  • 4
  • Remember: Well, it depends. One scenario why should you : If `MyObj` class is managed, then GC will take care of disposing, but if it involves unmanaged resources, you should take care to properly dispose the unmanaged resources and hence you should write a dispose function. BTW, `MyObj` is a wierd name given to a class. – now he who must not be named. Dec 02 '13 at 05:07

2 Answers2

0

It depends.

If your object creates unmanaged resources such as bitmaps, streams, etc.. then it should implement IDisposable and have a Finalizer so that these resources can be cleaned up.

If not.. then the Garbage Collector will collect it when it decides it wants to.

There are many questions/answers on this site, MSDN, etc that answer this question. Most books deal with this at some point too.

Here are some questions on StackOverflow that answer your question in much more detail:

Proper use of the IDisposable interface

Do you need to dispose of objects and set them to null?

Finalize/Dispose pattern in C#

Community
  • 1
  • 1
Simon Whitehead
  • 63,300
  • 9
  • 114
  • 138
  • There is no need for a finalizer if you're only using unmanaged resources that already have managed wrappers. This includes "bitmaps, streams, etc". All of those already have managed wrappers, and so will already be finalized. – Joel Coehoorn Dec 02 '13 at 04:57
  • @JoelCoehoorn Should I rephrase that to point out that the garbage collector will.. at some point.. finalize these resources? My point is that you can clean them up when your wrapper is finalized.. instead of waiting for the Garbage Collector to finalize them later. – Simon Whitehead Dec 02 '13 at 05:01
  • @SimonWhitehead that's what disposable is for. You don't need to clean them up when your wrapper is finalized, because the managed object will be finalized at about the same time. – Joel Coehoorn Dec 02 '13 at 14:33
0

The only reason you ever need to worry about Dispose()/IDisposable is if you're dealing with a resource other than memory. This includes database connections, sockets, GDI resources, file streams, and some other things. If you just have a POCO (plain old CLR object), there is no need for IDisposable.

The only reason you ever need to worry about a finalizer is if you're already building a type that implements IDisposable, and there is not already a .Net class that will finalize this resource. Everything mentioned above (database connections, sockets, GDI resources, and file streams) already has a .Net class that will finalize the resource, and so you do not need a finalizer, unless you're doing something like building a whole new kind of database.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
  • There are cases where memory-only resources are considered unmanaged and as such should also be disposed of. I understand what you're saying but it's a rough edge to walk... – M.Babcock Dec 02 '13 at 05:05
  • It's unfortunate that Microsoft failed to clarify what constitutes n "unmanaged resource"; the defining characteristic is not that it's an entity controlled by the underlying OS, but rather that it represents something which some outside entity (often, but not necessarily the OS) is doing and will continue to do on behalf of an object, to the detriment of other entities, until given notice to stop. For example, the OS may grant an object exclusive access to a file, preventing any other entity from using it. – supercat Dec 02 '13 at 17:15
  • 1
    While the most widely-recognized types of unmanaged resources represent things outside the world of managed code, some unmanaged resources to exist entirely within the managed code universe. For example, an observer object may ask for notifications every time an observable object changes. Such event subscriptions may be handled entirely within managed code, but would nonetheless represent an unmanaged resource, since the observable object will at minimum keep some memory allocated on behalf of the observer until told not to. – supercat Dec 02 '13 at 17:20