Yet another question on leaks..

[Exide]

Hello.
I can never remember what leaks (I'm quite sure nearly EVERYTHING does), and what to do about it.

1. Does units leak?
I.E: I use a local unit variable to be the target of my spell. Do I need to clear this variable in the end somehow?
I was thinking: 'set unit_variable = null', correct?

2. Same thing with special effects?
'call DestroyEffect( effect_variable)'
'set effect_variable = null'
-Like that?

3. If yes on 1, What about unit groups?
'call DestroyGroup( group_variable )'
'set group_variable = null'

Thank you in advance.

 

[~GaLs~]

>>I was thinking: 'set unit_variable = null', correct?
Yes

>>-Like that?
Yes

>>If yes on 1, What about unit groups?
Same as 1 and 2

 

[Exide]

I was right on all three questions? Cool!
Thanks for making it clear. +rep.

 

[Ghan]

For units, only local units leak. Globals do not.
All Special Effects leak.
All Unit Groups leak.

 

[Rheias]

Going into more detail if you don't mind...

Units don't leak. Actually most handles don't leak, however, when you store them into a local variable, there is a problem. If you forget to set a local handle variable to null it would leak, the game will be forced to remember it, but you could not refer to it as it is a local, which can be refered to only in the function that it was created in.

Think of a regular leak, when you store in some variable a location, it leaks, you must destroy it after use, this how local variables work, they store information, you need to remove that information from them, and this is done by setting them to null.

Now, saying that globals don't leak might be misleading. They do leak, but globals, unlike locals, can be refered from anywhere, thus assigning a new (none leaking) information to them, will remove the previous one, instead of creating a whole new variable. More then that, you can clean them wherever you wish. In locals the case is different, since you always create new ones and you can never refer to the previous ones easily.

I hope this makes it cleaer.

 

[SFilip]

Well you need to understand a definition of a leak first.
Everything created and not destroyed until the end of the game would count as one.
With this logic - just about everything can leak. But units have this thing...they die, and get removed automatically at some point after death.
Dummy units and similar probably wont die unless you make them. Always put an expiration timer to these (unless of course they are permanent and are supposed to stay for the whole game).

Now apart from this all handle-derived local variables can leak if they aren't nulled and their contents will be destroyed at some point. The second part implies that players (and heroes unless removed with a trigger) don't need to be nulled, but that's about it. Make sure you set any other handle local to null at the end of the function.

 

[Exide]

Thanks a lot for your answers.
I think I got it now.

 

[quraji]

In other words, all local handle (non-integer, non-boolean, non-real, or non-string) variables need to be nulled before the end of the function, or they'll leak.

 

[Rheias]

> (non-integer, non-boolean, non-real, or non-string)

Not really. First of all code doesn't needs to be nulled. Players don't as well. Also not globals triggers etc... Just follow what SFilip said.

 

[quraji]

You forgot the "local handle" part ^.^

 

[Exide]

I have a new question.

how does:
set bj_wantDestroyGroup = true
work?

First of all, the fact that it's name contains bj bothers me.
Secondly, why are there two ways of destroying a group?
Is one better than the other, and how does bj_wantDestroyGroup work?

Thank you.

 

[phyrex1an]

function ForGroupBJ takes group whichGroup, code callback returns nothing
    // If the user wants the group destroyed, remember that fact and clear
    // the flag, in case it is used again in the callback.
    local boolean wantDestroy = bj_wantDestroyGroup
    set bj_wantDestroyGroup = false

    call ForGroup(whichGroup, callback)

    // If the user wants the group destroyed, do so now.
    if (wantDestroy) then
        call DestroyGroup(whichGroup)
    endif
endfunction

The same pattern is to be found in most other bj functions that uses groups. The DestroyGroup way is better than bj_wantDestroyGroup. It doesn't rely on the bj functions and it's easier to see what actually happens.