Local variable lifetime
BlitzMax Forums/BlitzMax Programming/Local variable lifetime
| ||
| I have a function... OnPaint() Which is required to create an instance of a Paint object, which is used to draw with. C++ creates a local variable, so that when the OnPaint function is finished, the variable loses scope and is removed from the stack immediately. When I create a local BlitzMax variable, it will last well beyond the scope of the function (in memory... Delete isn't called until GC decides to). Having this around after the OnPaint causes issues on Windows. I have worked a way around it, by making a call to my Paint object's Free() method, which frees the under-lying data, and removes the problem. Without explicitly asking the GC to cleanup, I guess there is no way around the problem, is there? I'm happy enough using Free(), if that's what it takes. |
| ||
| Local variables are cleaned up on the next automatic GC call if they went out of scope. But this happens ONLY when you are in Strict or SuperStrict. Without Strict, you don't have any local reference checking and using local might cause quite some interesting stuff. What I actually don't see is why it should cause problems. You can't use the object anymore after it went out of scope, so how should it interfer at all, unless you gave it some automatic "handling" which is a quite bad idea on a local object that is meant to life within a "time box" (ie from start to the end of the function at max with no interaction to the outside, otherwise it wouldn't be a local) |
| ||
| Couldn't it be a problem when the GC deletes the already deleted object? Having this around after the OnPaint causes issues on Windows. Wich issues? It sounds very strange without more info. don't get me wrong, I believe you, it is just a matter of curiosity as I've never get this kind of things with BlitzMax. Is this variable pointing something 'outside' the blitzmax code (a pointer used from internally called C or C++ code)? |
| ||
| Is this variable pointing something 'outside' the blitzmax code Yes, which is required not to exist any more at the end of the OnPaint() function. In C++, this variable would be GC'd away automatically, because it is created on the local "temporary" stack. I may stick with the "make sure you call Free() when you are done" method, for ease of implementation. |
| ||
| In C++ nothing is GCed, as C++ has no GC, so a little strange comparision :) It will just be freed due to the fact that its whole stack frame is removed. Thats a major difference between managed and not managed languages. But yes if you use external objects you need to be free for sure at the end of the function, do it manually. As the documentation clearly states: never do anything, that needs to be done at a specific moment within the delete as there is no execution order guarantee nor execution time guarantee for the cleanup through the GC. Or to make it worse: if you call end within your app, NO further delete methods will be called! |
| ||
| Just a nerdy question related to GC: Is GC a thread that examines your variables' states periodically parallel to program execution or is it compiler inserted code that does the same but while the code is halted, if this makes sense. How many languages have no GC at all? That is, how many require you to clean your mess(es) yourself? Are there advantages to this? (Other than being able to say that you are using a truly pure language that only compiles YOUR actual code without any 'fluff'). ;) Russell |
| ||
| Ok, That was the only situation I could thing of. Could this be releated to the GDI+ library? GDI+ architecture is not exactly managed code friendly... I don't know exactly what are you at, but I managed to solve this on C# by creating the variable in the function 'caller' passing it as a parameter, and the same function caller 'frees' the variable inmediatly after the function call. That makes the unmanaged functioning of the variable transparent to managed code (in this case, the module user). I supose OnPain is a sort of event or 'event connector' on wxWidgets, so this could be doable. If I'm wrong, just forget it. :D |
| ||
| creating the variable in the function 'caller' passing it as a parameter, and the same function caller 'frees' the variable immediately after the function call. :-) That was one way I considered too, but that requires me to add a lot more logic in order to work for a specific event (namely the paint event). So yes, you were right ;-) And... at the moment I have too much other code to sort out before I need to worry too much about this - I can always come back to it and apply that kind of logic if it's going to be better for everyone. |
| ||
| Or to make it worse: if you call end within your app, NO further delete methods will be called! Oh dear. I always put End on the last line of my program, just for completeness. Is that ok? |
| ||
| As long as no important code that has to be called is in any delete method. |
   |