-
Sep 21st, 2004, 08:09 AM
#1
Thread Starter
Fanatic Member
garbage collection with .net
If I create an instance of a business class :
Code:
Dim lclsEmployee = New clsEmployee
Do I have to worry about clearing it out when I am finished with it ?
Last edited by venerable bede; Sep 22nd, 2004 at 09:40 AM.
-
Sep 21st, 2004, 08:32 AM
#2
No, the garbage thing does that for you.
However, if you are like me, and place code in the terminate event (VB6) of the class then this will annoy you.
The event in VB.NET is the Dispose event.
To run code when the class terminates you must override this dispose event
Not too happy with it myself yet.
Woka
-
Sep 21st, 2004, 09:37 AM
#3
Thread Starter
Fanatic Member
I've never used VB 6.o so you've lost me Woka.
Wuff
-
Sep 21st, 2004, 10:09 AM
#4
U've never used VB6?
But you post in the VB 6 section...in fact, what the hell are you doing on the site you deranged Georgie
In VB6:
clsEmployee
VB Code:
Private Sub Class_Initialize()
MsgBox "Woof"
End Sub
Private Sub Class_Terminate()
MsgBox "Badgers!"
End Sub
Then in a form:
VB Code:
Dim objSomeone As clsEmployee
Set objSomeone = New clsEmployee 'This cause the initialise event to fire, and a woof msgbox.
Set objSomeone = Nothing 'This causes the terminate event to fire, and a badger msgbox.
Does that make sense?
Anyways, .NET doesn't work like this.
You have new instead of Initialise.
VB Code:
Public Sub New()
'code here when object is created
End Sub
This has more potential as you can do:
VB Code:
Public Class clsEmployee
Public Sub New(ByVal EmployeeID As Long)
'code here to laod Employee from ID
End Sub
End Class
Then in a form you can do:
VB Code:
Dim woof As New clsEmployee(54)
Dim woof As clsEmployee = New clsEmployee(67)
both lines do essentially the same thing.
Woof
-
Sep 22nd, 2004, 08:56 AM
#5
Thread Starter
Fanatic Member
I already know that.
Woof.
I never post to the VB 6.0 forum. You must have me on you're mind a lot you perv badger.
-
Sep 24th, 2004, 05:03 PM
#6
Banned
Although there is a garbage collector it should not be regarded as not trying to clean up memory. In fact the way the garbage collector works is much like java's garabage collector.
You should use try catch finally blocks and close your db connection as well as release resources in the finally block
try
catch
finally
myConn.close()
myConn = Nothing
-
Sep 25th, 2004, 10:08 AM
#7
PowerPoster
Originally posted by jhermiz
Although there is a garbage collector it should not be regarded as not trying to clean up memory. In fact the way the garbage collector works is much like java's garabage collector.
You should use try catch finally blocks and close your db connection as well as release resources in the finally block
try
catch
finally
myConn.close()
myConn = Nothing
You only have to do that with resource intensive objects such as the connection object, image object, etc...
All others just let them go out of scope, much easier and it really has no impact on performance.
-
Sep 26th, 2004, 12:57 AM
#8
Frenzied Member
Don't let any of those crazy c++ programers hear you say that, Hellswraith.
Magiaus
If I helped give me some points.
-
Sep 26th, 2004, 04:55 PM
#9
PowerPoster
Originally posted by Magiaus
Don't let any of those crazy c++ programers hear you say that, Hellswraith.
Only reason they would have a problem with that is if they don't understand the garbage collection process.
Once a object is allocated in memory, that space isn't freed up unless the garbage collector frees it up. It doesn't matter if you set the reference to null before you leave the method or if you let it drop out of scope, both produce the same action as far as the garbage collector is concerned.
Database connections though are different. They hold references to unmanaged resources. This means you need to call the .Close() methods or .Dispose() methods of those types of objects so the object itself can release the resource it is using immediately instead of waiting around for the garbage collector to come along and free it up by destroying the connection object which is no longer referenced by your app.
-
Sep 26th, 2004, 05:27 PM
#10
Frenzied Member
Very true. I'll go ahead and mention, just for the heck of it, that if you do doubt this you can call System.GC.Collect(), but it isn't recommened because it requires the extra proccess time.
The only reason I said anything is because I was reminded of a thread with CorneedBee talking about how arrays are so ineficient if you ReDim. You may remember it you explained about creating a ReDim function the allowed you to preserve an existing array.
I always trust your advice my friend.
Magiaus
If I helped give me some points.
-
Sep 29th, 2004, 10:28 PM
#11
PowerPoster
Originally posted by Magiaus
I always trust your advice my friend.
That is scary, since even I don't trust my own advice...lol.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|