Object created by new inside a function

W

Worrow

Regular
Joined
Jul 10, 2003
Messages
68
Somthing like this:

private void DoSomthing()
{
AA a = new AA();
// do somthing with a
a.Dispose(); //
}

Is it necessary call the last line (a.Dispose) ? In C++, I would do it w/o second thought. But in C#, I am not so sure about it.

Any suggestion? Thanks in advance.
 
Dispose and scope

You should always call Dispose on disposable objects once you have finished using them. Most objects which have this method are likely to have a finalizer as well and so by calling Dispose finalization can be avoided, releasing any unmanaged resources and allowing the object to be garbage collected earlier.

The obvious question is - do locally allocated objects get automatically collected when they go out of scope? I haven't found any information to suggest they do, and it seems very unlikely.

The question itself is misleading - objects do not go out of scope, variables do. Only when an object has no variables referencing it (roots) can it be disposed of by the runtime. During the method, the variable may have been assigned to another variable with a wider scope, and so the object should not be disposed of as it is still in use. Also, the local variable might be assigned to multiple times, or assigned to a variable from a wider scope. Basically, the compiler or runtime would need to be extremely careful to decide whether to dispose of an object when a variable goes out of scope.

Note that there is also the using construct which performs disposal automatically at exit:

C#: 
using (AA a = new AA()) {
    //Do something with a
}
//a is disposed of here and goes out of scope

Good luck :)
 
Re: Dispose and scope

Are you talking about DotNet Framework objects, classes you are writing, or objects in general? Do you understand the IDisposable interface and the difference between Dispose in DotNet and delete in C++?

To answer from a slightly different angle, simply put, managed resources (resources on DotNet's own heap) are automatically collected for you. When unmanaged resources are allocated (such as Windows handles and objects from unmanaged libraries) they need to be released explicitly, which is where Dispose comes in. If it is there, call it when you are done with an object, as you would do in C++ (or try the using keyword). When it isn't, don't worry, DotNet will take care of it. When you are writing your own classes that use unmanaged resources, implement IDisposable and release the resources in the Dispose method.
 
Re: Dispose and scope

What about using an object created from a COM or an EXE library? How do I dispose such objects? But then again do I really need to dispose them?
 
COM and IDisposable

Imported COM objects do not implement the IDisposable interface so there is no need to dispose them - infact it's not even possible.

:)
 
Re: Dispose and scope

I'm not too sure about COM components. I would guess that if they expose a Dispose method, that would be the way to go, and if not, you shouldn't worry about it, but you probably want to check out MSDN documentation on COM in DotNet and check out the COM classes located in the DotNet framework. Or find someone who knows what they are talking about.
 
Re: Dispose and scope

I did some testing with the garbage collector, (specifically with respect to using Excel automation, where I was doing something similar to:

Code: 
	Dim objApp As Excel.Application
	objApp = CreateObject("Excel.Application")

	' ... do some work ...

	objApp.Quit()

I found that the COM resources were not being specifically released until I exited the program. In the case where I re-used this function, the resource usage would increase linearly.

Task manager would also display an EXCEL.EXE running which would not actually terminate until I did so manually (even after my application was terminated)

The solution to my problem was:

System.Runtime.InteropServices.Marshal.ReleaseComObject(objApp)

followed by a

System.GC.Collect()

The releasing of the COM object seems to trigger the equivalent of a .Dispose().

I forced the GC.Collect, (the discussion for whether this is appropriate or not has been made before) to ensure that the EXCEL.EXE application in the task manager was terminated immediately.

P.
 
Back
Top