Player Variables Don't Leak?

If you do H2I(p1) and compare it to H2I(p2) you'll find they are the same. So. Do local player variables really leak?

No they don't, you don't create new players ...

(You can't leak their handle ids if you never create/destroy them)

This means you don't have to nullify them.

Yea, I was always nulling player variables.

xombie = FAIL

Just to be completely clear, are there any other handle types that work this way? I thought that there were two leaks, one with objects (creating/destroying) and then another with variables, for instance.


I thought that not only would the actual "trigger" created by CreatTrigger() would leak, but as would the variable t. To be a little more clear...


Now you still have your variable, which needs to be nulled. How is it that no memory is leaked when space is allocated for the "player" variable.

Because the player variables function more like constant references. There are a finite number of players and whenever you declare one you 'substitute' in that reference. This means that every declaration of a given player carries the exact same value, hence an identical H2I. You can never 'create' a new player, whereas with your example you can indeed create a new trigger.

Okay, well I suppose it won't cause me any trouble anyways, since the only tampering you really need to do with players is in actual game code.

Player() and all the GetConverted____() functions are native equivalents of I2H()

Any type that uses such functions never need to be nulled.

I also don't think lightnighs, texttags, terraindeformations and a few other weird ones like that need to be nulled, but that's just a shot in the dark...

Oh, and boolexprs never need to be nulled. Or destroyed. (Unless you use it only once, ever. But even there, considering how buggy JASS is with destroying things, it's probably best to leave well-enough alone.)

terrain deformations (atleast perm ones) are never removed, even when they are destroyed. They leak their reference and still keep their performance loss after being destroyed.

Sounds don't have to be nulled either, unless you destroy them (which you never should).

You need to understand what a "variable leak" means. Each handle adress keeps a reference counter of how many variables are pointing to it. It can only get recycled for another handle if that counter is zero (and, of course, if the handle stored at that adress is destroyed). There is a bug where local variables don't properly decrement that counter at the end of a function, so we have to do it manually, else the handle index will not get recycled for a new handle once the one stored there is destroyed and you'll get handle index inflation which can degrade performance a bit. Obviously, this doesn't matter at all for handles you will never destroy, like players.

I didn't really understand that last one.

You dont need to null static objects.

Alright well if I have any further questions I can always post here. Thanks for all your help.

If player variables don't leak like that, and I do...


Do I only need to null one of them?

... a unit isn't a player

players cant leak because they never get destroyed, so its impossible

that would leave reference count to unit as 1, so yes it would leak

Makes sense. Derr.