Returns of functions

[Altras]

Hi all!

I wonder if someone of you knows how are returned objects in a property or a function.

For example i've got a function caller:

dim a as new object
a = getObjectA()

and a function:

Public function getObjectA as object
  try
    dim objReturn as new Object
    return objReturn
  catch ex as exception
  finally
    objReturn = nothing
  end try
End sub

I would like to know:

Will the function return a copy of the object or a reference?
Will the line 'objReturn = nothing' destroy returned object ?
How can i be safe when disposing an object?

In the past, I have got many problems because i didn't dispose objects and now that i want to dispose them, im stuck with "Object disposed" errors.

Is there someone who can help me?

Regards
Pat

[gigemboy]

Have you tested that code first?? The Finally block might be ran regardless, thus always returning nothing as the object, it was posted in this thread a few days ago. You would probably need to set the objReturn=Nothing after the "catch" statement, not the "finally" statement. In regards to your first question, you didnt specify whether you declared the object ByRef or ByVal, which is what you choose.

[jmcilhinney]

Setting a variable to Nothing does NOT Dispose an object. You should always call the Dispose method of objects that support it when, but ONLY when you have finished using them. You wouldn't throw something in the rubbish bin if you wanted to use it again would you?

Your application has two areas of memory: the stack and the heap. The stack is where variables are stored. If a variable is a value type, like Integer, Boolean, Date, etc. then the variable contains the value of the object. If the variable is a reference type, i.e. any class, then the variable contains the address of an object on the heap. If you set a variable to Nothing then the stack location is filled with zeroes. For a value type that resets the value to its default, like zero for a numerical type. If the variable is a reference type then it will then contain the memory address null, which means that it refers to no object. The object on the heap that it did refer to is completely unaffected though. If it wasn't Disposed then it will still be holding onto precious system resources. When an object on the heap has no variables that refer to it then it is marked for garbage collection, which means that the .NET Framework will clean it up at its leisure. There is no guarantee that this will be any time soon though, so it may hold onto resources for some time. Also, undisposed objects take an extra cycle of the garbage collector to be cleaned up.

[jmcilhinney]

To answer your original question, setting the objReturn variable to Nothing is completely pointless because the variable loses scope, and thus ceases to exist, the very next line. Also, Object is a reference type so the function returns a reference to an object on the heap, not a copy.

[Shaggy Hiker]

To answer your original question, setting the objReturn variable to Nothing is completely pointless because the variable loses scope, and thus ceases to exist, the very next line. Also, Object is a reference type so the function returns a reference to an object on the heap, not a copy.

I'd want to test that to be certain. After all, there was the Return objReturn statement prior to the finally. It appears that this sets the return to the same address as the variable. You then clear the variable in the Finally block (which does execute, even after the Return statement). This has not deleted the object from memory, but what remains in the Return value if objReturn is a Reference type? It shouldn't do anything if it is a value type.

[Shaggy Hiker]

Hah! It doesn't even compile. objReturn is declared in the Try block and is not in scope of the Finally block. However, once that is rectified, it is as JM said, the return remains valid, so the return is a copy of the pointer to the object on the heap, and setting the variable to nothing sets that instance of the pointer to 0, but doesn't affect either the object on the heap (of course), or the copy in Return.

I had thought that return might be a special case, one where the value is not quite defined until after the Finally block has executed. Nice. Hadn't thought about it that seriously.

[Altras]

Sorry for the error in my example, i was trying to give an quick example of my current situation... and i didnt tested the code.

Hopefully, you were both able to correct it and you really understood and answered my interrogations

But, i would like to know... is there a difference if I change the function caller:

dim a as new object
a = getObjectA()

for this:

dim a as object
a = getObjectA()

In that case, will the object returned still be a copy of the pointer?
There might be a diffenece between these cases.

There is a little difference about instances of pointers and instances of objects. When a function return a "reference type" like Object, will it copy the pointer only or the entire object?

Last question (there are a lot!): When we are creating classes (for example class cChair) is it by default a reference or a value type?

Thanks again
Pat

[jmcilhinney]

This:

dim a as new object
a = getObjectA()

declares an Object variable, creates a new Object instance and assigns it to that variable, then throws it away when it assigns the return value of getObjectA to that same variable. This:

dim a as object
a = getObjectA()

declares an Object variable and assigns the return value of getObjectA to that variable. There's no difference in the return value of the method or what object the variable ends up referring to. The only difference is that the second code doesn't wastefully create an object that is never used and immediately discarded.

What it comes down to is this: a function returns a stack variable. If the return type of the function is a value type, i.e. a structure, then that stack variable contains an object, so it's a copy of the object. If the return type of the function is a reference type, i.e. a class, then the stack variable contains a reference to an object, so the object is not copied. Reference type objects are never copied unless you explicitly do so by calling Clone, Copy, invoke a copy constructor or something like that. Your code passes around stack variables. Stack variables are what is copied over and over. If the variable contains an object then the object is copied. If the variable contains a reference then the object is not copied. It all comes dowen to value and reference types.

[Shaggy Hiker]

I assume that this is just an example, and there is a more substantial function than the one you posted. As it stands, the function does nothing of any value. However, this got me thinking about what happens if an exception is thrown in a constructor. I seem to remember that exceptions wouldn't propagate out of C++ constructors, so I thought I'd test what happens with VB.NET constructors.

If an error is thrown in the constructor, the object is not left in a partial state, it remains as Nothing. Therefore, wrapping the constructor statement in a Try Catch block really doesn't require a Finally block. The object will be constructed to a valid object, or it will be nothing. Thus you could re-write the above example as:

Public function getObjectA as object
 dim objReturn as Object
  try
    objReturn = New Object
   catch ex as exception
  finally
    return objReturn
  end try
End sub

And get the same functionality. Seems kind of pointless in this case, but I imagine this is just a simplification.