The case of the missing a
BlitzMax Forums/BlitzMax Programming/The case of the missing a
| ||
Strict Type a Method New() DebugLog "im here" End Method Method Delete() DebugLog "im gone" End Method End Type For Local i = 0 To 1 DebugLog i gah() Next GCCollect() Function gah() Local test:a = New a test = Null End Function DebugLog:0 DebugLog:im here DebugLog:1 DebugLog:im here DebugLog:im gone |
| ||
If you add another field which identifies the object you will see that final "im gone" is really the first object, the one called 0. After setting test = Null the garbage collector can reclaim that memory whenever it wants to. It got around to doing the first one. But apparently the second one is not needed because the program ends and all memory is returned to the OS. At least that's what I would guess is the explanation. |
| ||
You can never be sure delete will get called on any objects after you end your program. No guarantees. |
| ||
If you need to have something happen every time an object is to be considered dead, it is best to do that with a manual call - obviously relying on the GC is not a good idea. |
| ||
But I read in another post that GCCollect before End will still collect everything. |
| ||
I always get 2 'gones'. Similarly whatever the loop count the 'gones' are always the right amount. I'm in Linux btw, are you in Windows? |
| ||
I always get 2 'gones'. Similarly whatever the loop count the 'gones' are always the right amount. I'm in Linux btw, are you in Windows? I don't get two 'gones' here on Linux.The last one is never destroyed for me: |
| ||
Two GCCollect() at the end of the program will destroy the last object. |
| ||
Two GCCollect() at the end of the program will destroy the last object. Not always.EDIT: Again, if you want something done when an object is to be considered dead, you must do it yourself. |
| ||
I'm doing it to make sure destroyed objects are being deleted and not retained, due to circular reference etc. |
| ||
Plash: how many 'destroyed' do you get now? When I remove MakeObject's parameter it goes from 2 to 3. Strange. |
| ||
Plash: how many 'destroyed' do you get now? When I remove MakeObject's parameter it goes from 2 to 3. Strange. Still two. |
| ||
add small delay before GCCollect: and all 3 are destroyed. but in threaded build this works without delay... |
| ||
Could be my system is slower and I don't need a delay. I'm using 1.40 on a dell 1525. |
| ||
The lesson is still that abandoned objects may or may not get garbage collected before the program ends. If there is any important clean-up that must be done then you should do it yourself. Don't rely on the garbage collector to do it automatically via Delete. |
| ||
Local test:A = New A.Create() Isn't this wrong? shouldn't it be either: Local test:A = A.Create() 'With the Create returning a new instance and printing stuff.or... Local test:A = new A 'Using the New constructor to print the stuff. |
| ||
Local test:A = New A.Create() No. In this case, Create() is a method not a function. Isn't this wrong?... |
| ||
Isnt the Debug log just being turned off before the last object is deleted? |
| ||
Isnt the Debug log just being turned off before the last object is deleted? I don't think the debug log can be turned off.This thread is turning towards silly drivel - the point has been made already people. |
| ||
Isnt the Debug log just being turned off before the last object is deleted? No. Czar and Plash have supercomputers so the GC doesn't get enough time to delete the last object. |
| ||
Enough time from where? Even with massive delays before and after the last one doesn't get deleted. |
| ||
My mistake then. See post #15. |
| ||
Interesting! PuttingOnEnd GCCollectsolves the problem, even with only a single GCCollect added. |