Terminating a Type from the inside
BlitzMax Forums/BlitzMax Beginners Area/Terminating a Type from the inside
| ||
| I am trying to make a command that terminate a type from the inside. Exmaple:
Type Test
Method Terminate()
Self=Null
End Method
End Type
'---Test Area---'
Local TT:Test
TT.Terminate()
offcourse this doenst work.. is there another way to do that beside externaly Nulling it (TT=null) |
| ||
| As soon as an object of your Type has no references it will be ready for garbage collection, and then will be collected later, at some point. In your test, you don't even have an instance of "Test", so your next line will fail anyway. Local TT:Test = New Test Then, to free the object, TT = Null The object will be garbage collected later. If you want to do something when the object is finally freed by the garbage collector, you can implement a Delete() method for it. However, at the end of a program, BlitzMax does not generally bother to garbage collect ever object it ever created, so there is a chance your Delete() methods may not be called for those objects who are still alive when your app terminates. |
| ||
Type Test Method Terminate(TT:Test) TT = Null End Method End Type Local TT:Test = New Test TT.Terminate(TT) Maybe you could just pass it into the method, but bruceys right, just let the garbage collector gobble it up :P oops, ignore my post |
| ||
| That won't work, because the local TT is still referenced. By passing it into the method you now have 2 references to the object. |
| ||
How about...SuperStrict Type Test Method Terminate(TT:Test Var) TT = Null End Method End Type Local TT:Test = New Test TT.Terminate(TT) If TT = Null Then Print "Presto!" |
| ||
| Kryzon. I think uv nailed it! Still need to check as im on the phone browser The var command was new to me. Also thanks brucey and supasm |
| ||
| Yay, thanks Brucey and Kryzon, didn't know about var either. |
| ||
| WTF did I just witness. :oO |
| ||
| Supasm. Are you talking about youself in this nice poem? Since you didnt solve the problem. |
| ||
| Cool as the code in post #5 is for illustrating Var, does it actually do anything other than provide a more difficult way to write 'TT = Null'? For that matter, what the real purpose behind the original question? Wanting to delete objects by hand is missing the point: you can't do that and you shouldn't want to do that; it's already done for you. Nulling variables serves no purpose (that is, if manually nulling nonglobal variables has any observable effect on program performance it usually means there's a design flaw, or more rarely a GC bug). If you want to guarantee that an object gets finalized (perhaps it owns a file handle or something), this will not do that either, as Brucey pointed out; you need to enforce it using a control structure of some kind. There are a few ways to do this but what you have above is not one of them. |
| ||
| Look. I dont really understand how this garbage collector works. I have a DataBase... ----------------------------------------- (just an example!) Type DataBase_Class field Cells:tlist() End Type type Cell_class field Data end type DB:DataBase_Class=new DataBase_Class ------------------------------------------ Ok... Now that its created how the hell will the garbage collector will pick it? how does he know whether ill use it or not in the distant future. The reason I dont want to use DB=null is because I need to clear all the cells first. maybe the cells are picked by the garbage collector that makes sense since its under the main type. anyway... someone told me once that nulling the main type doesnt cancle the subtypes so I thought I need to null them before nulling the main Type (which is the database) any way example #5 does what exactly I want so its fine with me! no more extra thanks.. |
| ||
| Ok... Now that its created how the hell will the garbage collector will pick it? how does he know whether ill use it or not in the distant future. Short answer: magic. Long answer: behind the scenes it maintains a running count of how many objects the reference has been assigned to. When this count hits zero there is no longer any possible way for you to use the object and it, seeing this, knows it can be deleted. This applies to all objects, so once the container has been freed, that reduces the reference counts of everything it holds as well, making them available for collection too. When you assign a value to a variable, e.g. "a = b", three operations happen: the reference count of whatever is currently in a is decremented; the value of b is assigned to a; the value of whatever is now in a is incremented. Because of the increment that happens to every value that gets assigned, anything being passed around in your code has a refcount of at least 1; when it hits zero it will mean that it hasn't been assigned to anything since the last reference was lost, and the GC can use its hidden reference to free it. However it will only do this when it is good and ready; setting a variable to Null achieves pretty much nothing because the reference would have been lost anyway when the function ended, when you overwrite with a different value, etc. In other words, the compiler inserts extra code around what you wrote, to provide the things you didn't write. You do not need to write code for this yourself. anyway... someone told me once that nulling the main type doesnt cancle the subtypes so I thought I need to null them before nulling the main Type (which is the database) As outlined above, this is completely wrong. Whoever said this either didn't understand GC, or was talking about Blitz3D. (To the extent that it means anything at all, anyway - a type is not an object, and "nulling" isn't the same as releasing a reference. You cannot delete a type, because a type is not a thing that exists.) example #5 does what exactly I want Example #5 doesn't do anything! Of course it's worth pointing out that "nothing" is exactly what you want to do, because the work is being done by the language runtime, but normally you wouldn't write code for the purpose of doing nothing. |
| ||
Type Test
Method Terminate(TT:Test Var)
TT = Null
End Method
End Type+1 everything Yasha said. In any case, I consider it bad form to write a method (which implicitly references the calling object) and passing an explicit reference to the same object as a parameter. Better to use a function. |
   |