Returning from a function without destroying objects

views:

126

answers:

+2 Q:

Returning from a function without destroying objects

Hi,

I have a function in C# 2.0 called Foo(), that returns a value of the type boolean. I am instantiating an object in the function that I am not destroying before returning the boolean value. I want to know whether is it necessary to destroy the objects created before returning the value?

thanks.

+1 A:

no. unless the object in question implements IDisposable, in that case wrap it in a using(){} statement

Chad Grant 2009-05-07 05:27:21

You should always implement IDisposable considering both possibilities: the user will explicitly (or implicitly in a using block) dispose the object and the user will not dispose the object. In the later situation you should implement a destructor that ends up performing any cleanup required.

David Rodríguez - dribeas 2009-05-07 05:54:36

@dribeas - you have the rule backwards. If an object has a destructor, it must also implement IDisposable. But if an object implements IDisposable, it is only rarely necessary to give it a destructor. e.g. the compiler creates iterator classes to support IDisposable and yet they have no destructor, a class that only holds references to other IDisposables should support IDisposable but will not itself need a destructor. It is almost never necessary to write a destructor in C# today. SafeHandle is a better tool for dealing with OS resources.

Daniel Earwicker 2009-05-07 06:12:39

+5 A:

No it isn't. If you Foo method creates value types, they are located on the stack and thus cleaned-up as the stack is unwound. If you create reference types, your reference to these instances will go out of scope as the method exits and the instances will therefore be up for garbage collection.

Brian Rasmussen 2009-05-07 05:27:40

Thanks for the explanation!

pradeeptp 2009-05-07 05:43:23

While it's true that in general there is no need to destroy the objects created by Foo explicitly, they are NOT allocated on the stack! In most managed languages there is a degenerate stack used for tracking function calls, and all objects are allocated on the managed heap.

Tal Pressman 2009-05-07 06:51:53

@Tal: Did you read my answer?! The first sentence is "no it isn't" as in "no it isn't necessary to destroy anything". Local value types *are* located on the stack. Objects or reference types if you will are always allocated on the heap.

Brian Rasmussen 2009-05-07 07:03:14

@Tal: Java didn't allocate on stack until it got escape analysis in version 6, but .NET allocates *all* value types on the stack by default

viraptor 2009-05-07 07:13:33

i hate to be contradictory, but no, no it does not. See my two recent blog articles on this very subject.

Eric Lippert 2009-05-07 15:13:59

@eric-lippert: Could you please clarify if your comment was directed at me or at viraptor. I assume it was meant for viraptor as value types which are part of a reference type will go to the heap along with the rest of the object. Was that your point?

Brian Rasmussen 2009-05-07 15:34:41

In C#, all objects are garbage collected automatically, and basically there is no way to explicitly deallocate an object, so no, you don't need to manually destroy objects.

If your object holds a resource, you want to be sure to release the resource, but you don't need to (can't) destroy the object.

Andy White 2009-05-07 05:28:22

It would be better if you use dispose method in case of i/o or db objects. Otherwise when you try to modify a file that was earlier referenced and not released then exception might occur.

You can also assign null to the object to remove the reference.

rahul 2009-05-07 05:32:59

ansaurus

tags:

views:

answers:

Returning from a function without destroying objects

related questions