PolarProjectionBJ - does it leak?

In a map I'm currently working on, polar projections must be called very rapidly. I remember someone said they leaked--not good when it will be called so frequently. Does anyone have any confirmation of this, or a solution that doesn't leak?

heh.. i'm not the pro at memory leaks but from what i can see it would leak 1 location. I think that people used to think it was much worse, but I dont think it is. especialy since it's is one function, if it does leak you only need 1 local to fix it.

Thanks! I was just wondering, because it will be called millions (probally more) of times (don't ask) in a map I'm working on, and 1 location would be a massive issue. I checkout it in blizzard.j, and just remove the leak and paste it in my map header.

Meh... it leaks in the sense that it returns a point that you have to destroy. The function itself doesn't use any locals, so no problems there. Just treat it like you would any other function that returns a handle.

There's function called PolarProjectionNL() floating around somewhere on wc3sear.ch, I think, that reuses the point you use in the argument by moving it to the polarprojected location. But that may or may not be what you want...

hmm, does everything that returns a handle leak? you know, excluding integer reals and such.

I don't know about integers and such... `pass by reference' and all that (in other words, does anyone know if integers leak?).. but handles do leak, yes, unless you destroy them. -does not quite understand the question-

oh, btw, if you're ever unsure if sth leaks, I have found it helpful to use the return bug to keep track of exactly how many handle objects are being created and destroyed ^ ^

(so you would do sth like,

function H2I takes handle returns integer
return h
return null
endfunction

function H2S takes handle returns string
return I2S(H2I(h))
endfunction

function CreateDestroyLoc takes nothing returns nothing
local location tempLoc = Location(10, -10)
call DisplayTextToForce(GetPlayersAll(), H2S(tempLoc)
call DestroyLocation(tempLoc)
set tempLoc = null
endfunction

and run it whenever you type `point'. If you were to delete the `set tempLoc = null', you would observe the numbers incrementing, thus demonstrating that pointer references leak when you don't reset local variables ^ ^ (or you could call PolarProjectionBJ on a global point, and also see the numbers incrementing.))

Oh, and I think the reason for rumors that they leaked more was because of the experiments done a year or so back that eventually caused people to conclude that locals leak handle references if they are not set to null; the initial assumption had been that returning locations leaked.

Actually, that function doesn't leak anything, it would only leak if you don't destroy the argument you gave to it or the result