//--------------------------------------------------------------------------------------------------
// About Types
//--------------------------------------------------------------------------------------------------
//
// -- Complex types and automatic deletion --
//
// Many native types represent "complex" objects (i.e. larger than 4 bytes). The script language
// automatically keeps track of these objects and deletes them from memory when they are no longer
// used (that is, when nothing in the script references them any longer). The types which benefit
// from automatic deletion are:
//
// abilcmd, bank, camerainfo, marker, order, playergroup, point,
// region, soundlink, string, text, timer, transmissionsource, unitfilter, unitgroup, unitref,
// waveinfo, wavetarget
//
// Other object types must be explicitly destroyed with the appropriate native function when you
// are done using them.
... say that we have a garbage collected type A. Now we want to track all A's created by our code so we use a collection (an array in this case) to store each A created. Now when we no longer wants to use our A we must remove it from that collection (akin to how you had to RemoveLocation when we no longer wanted it) or else garbage collection will never take place.
I guess memory leaks never existed then since your computer has a pre-defined memory pool... Though, fair point. If you can't allocate new memory then memory leaks doesn't exists. But you can allocate new memory in sc2. The question is, can any of these data structures you create reference another data structure? In that case, garbage collection doesn't solve all your leaking problems. Besides, manual allocators (such as unit indexer) are also subjects to memory leaks as you say "You will however have to clean it up somehow".@ phyrex1an:
You will not leak memory since your global variables / arrays have a pre-defined size. You will however have to clean it up somehow because otherwise you will end up with code starting to act weird or even crash when that array is completely full.
Me too. Citing myself: "unless we want to introduce false positives, an extreme evil". Though it would be neat if a garbage collector could solve the halting problem and remove all memory that I will never use again automagically...I would very much complain if it removed something I've still stored somewhere.
Well, perhaps I'm liberal in my definition but memory that hangs around that I no longer wants to use is a memory leak in my book. Some language designers agree with me though and introduces stuff like weak references and other kludges.That's not a leak either in my book.
if we can't even agree on what a leak really is then there isn't much to be said about the subject...
What? Did no one read my post? There is no destroy group, it actually destroys the objects when you no longer need them, like Java or something else...So, to express it with JASS terms: You need to DestroyGroup(), but you do not need to set group = null after that.
Um no, that's the point. It actually destroys the objects when you no longer references them [from the global scope]. Memory leaks are still possible, just like in Java or something else.it actually destroys the objects when you no longer need them
So basicly its the exact opposite of what I said: Always null every handle variable properly, to make sure you kill the reference to the object. I didnt know that Galaxy doesnt have destroy funcs anymore. ... Weird. As if blizzard wants to force us to generate unclean code.Um no, that's the point. It actually destroys the objects when you no longer references them [from the global scope]. Memory leaks are still possible, just like in Java or something else.
Edit: Though, a destroy group equivalent isn't the solution... The solution is to make sure that you no longer reference stuff that you want garbage collected.