Deleting a Instance

  • Thread starter Thread starter Mike
  • Start date Start date
M

Mike

Folks, I'm more of a C/C++ programmer and still learning the final
details of VB "oops"

In VB.NET how do you delete a object? For example

sub DoSomething()
dim u as new TUser("Mike")
....

End sub

I don't see how you deallocate the u instance of Tuser? Should I
presume VB.NET will deallocate this new instance once the local scope
is lost?

Generally, like in C/C++, if you allocate it yourself (new), then you
are responsible for releasing it.

I don't see an issue with this:

sub DoSomething()
dim u as TUser
....

End sub

Because that is an inherit local scope allocation and therefore the
compiler will remove it automatically.

But what about when you use new?

Thanks
 
Folks, I'm more of a C/C++ programmer and still learning the final
details of VB "oops"

In VB.NET how do you delete a object? For example

sub DoSomething()
dim u as new TUser("Mike")
....

End sub

I don't see how you deallocate the u instance of Tuser? Should I
presume VB.NET will deallocate this new instance once the local scope
is lost?

Generally, like in C/C++, if you allocate it yourself (new), then you
are responsible for releasing it.

I don't see an issue with this:

sub DoSomething()
dim u as TUser
....

End sub

Because that is an inherit local scope allocation and therefore the
compiler will remove it automatically.

But what about when you use new?

Thanks
Click to expand...

..NET uses garbage collection. Once there are no more live references
to the object, the object becomes eligible for garbage collection. You
don't do anything to explicitly release it. If the variable that
holds the reference to the object has a lifetime longer than the time
that you need the object (such as a local field in a form or class)
you can set the variable to Nothing to make the object eligible for
garbage collection before the variable goes out of scope.

In .NET there is no concept of an object living on the stack like in
C++. There are only references to objects in the heap (except for
value type items like Integer, etc., which are not objects).

However, if the object implements IDispose, then you should call the
object's Dispose method when you are finished with it to allow the
object to free any unmanaged data it uses, such as file handles, etc.
The easiest way to do this is with Using / End Using:

Using u As New TUser
....
End Using
 
Mike,

This is the same oops as in managed C++.

The garbage collector takes care of releasing the managed objects as soon as
there is no reference too or from it anymore, however the garbage collector
runs not all times, but is managed to do in fact as the best time. (With all
things which are managed, there are always persons a shore who think that it
can be done better.)

Take by instance an object that is used as a datasource, then the old object
stays alive as the reference in the datasource is the same as the old object
(and will be used, one of the most made mistakes).

Normally there is nothing you would have to do extra.

However, if the object still uses unmanaged resources, then you should use
the method to release these unmanaged resources which has the name dispose
(unmanaged resources) that method it is inherited from components, which is
the base of all components which you drag by instance of your screen.

You find that dispose method as a kind of appendix in 20% of the classes, it
is less needed by newer classes which are completely Net. Be aware that for
Net components which are simply a kind of wrapper around a com object (by
instance in SharePoint), you have to release the unmanaged resources.

However as you have not implemented the IDispose method in any way, using
the dispose method means almost nothing (it tells that the object can be
earlier processed by the Garbage, this does not mean that the object is
released, I would let it do at its normal time, but about this not everybody
agrees)

The Idispose interface is mostly implemented automatically by the templates
which you use at the start of a project (by instance in a windosform project
but not in a console project).

Be aware that Microsoft classes which have the method Close, automatically
do that disposing of unmanaged recourses for you in the close.

Cor
 
Wonderful Jack and Cor! I appreciate the detailed internal
descriptions. Make sense and I have much to catch up with .Net. :-)

Thanks to you both

--
 
Jack Jackson said:
<big snip>

However, if the object implements IDispose, then you should call the
object's Dispose method when you are finished with it to allow the
object to free any unmanaged data it uses, such as file handles, etc.
The easiest way to do this is with Using / End Using:

Using u As New TUser
....
End Using
Click to expand...

Jack,

Are you saying that GC does not call Dispose?

Thanks, Bob
 
Jack,

Are you saying that GC does not call Dispose?

Thanks, Bob
Click to expand...

No, GC does not call Dispose. GC calls the objects Finalize method.

The IDisposable Interface and it's associated pattern are there so that
developers can attempt to implement RAII (Resource Acquisition Is
InitializatioN) in a non-deterministic language.
 
No, GC does not call Dispose. GC calls the objects Finalize method.

The IDisposable Interface and it's associated pattern are there so that
developers can attempt to implement RAII (Resource Acquisition Is
InitializatioN) in a non-deterministic language.
Click to expand...

Also, and for the .NET objects that implement IDisposable, you can use
"Using-End Using" blocks without needing to call Dispose explictly.
 
Back
Top