| 03-28-2004, 09:34 PM | #1 |
Heh.... This is the 3'rd time I rewrite this thread after results of new tests. Originally I was gonna confirm that the return-bug wierdly enough did not stamp your passed handles with a reference but then I began to test more and more, and found out the following.... (Oh, and don't read this thread if you are not experienced with memory leak and JASS, as you may draw wrong conclusions). Local variables defined in the header of a function (parameters) do not affect the ReferenceCounter of the handle. This in itself is pretty amazing. I guess some of you may have suspected as much after looking closely at a few blizzard.j funcs ... but, what this realization means, is that: 1. Most of the blizzard.j function do not in fact leak memory. 2. The Return bug does not stamp its passed handles with a reference. 3. You have a easy way to return a handle without leaking the reference. Which i'll explain now: If we'll just go with a example often played with in this old, great thread: http://www.wc3campaigns.com/showthread.php?t=32805 Code:
function CreateLocation takes location loc returns nothing set loc = Location(0,0) call RemoveLocation(loc) endfunction function Test takes nothing returns nothing local integer i = 0 loop exitwhen i >= 5000 call CreateLocation(null) set i = i + 1 endloop endfunction This code won't leak a thing. So, how can this be useful for you? Well, we know by now that we can avoid leaking references to a location while returning by just creating them on the spot (return Location(x,y)). And with groups we can ofcourse just edit a passed group. But this is a different method, and requires you just to define your return-variable in the header, and pass it "null" (or in reality whatever). This ofcourse can be considered a kind of sloppy fix, but it works, and is personally kinda simple. This can ofcourse also be implemented into a dummy function that just references the real function, as demonstrated here: Code:
function CreateLocation_Main takes location loc returns location set loc = Location(0,0) return loc endfunction function CreateLocation takes nothing returns location return CreateLocation_Main(null) endfunction Anyways, that's what took me all day long to play with. And atleast it'll be very useful for me. Cubasis |
| 03-29-2004, 04:11 AM | #2 |
Now thats interesting. Makes sense too, in crazy blizzard logic. |
| 03-30-2004, 07:30 PM | #3 |
Not surprising news :) The trick with 2 functions is a nice one. I'd like to point out that PolarProjectionBJ still leaks, so I don't know what bliz.j functions you are talking about when you say "1. Most of the blizzard.j function do not in fact leak memory." |
| 03-30-2004, 08:27 PM | #4 | |
Quote:
Code:
function PolarProjectionBJ takes location source, real dist, real angle returns location local real x = GetLocationX(source) + dist * Cos(angle * bj_DEGTORAD) local real y = GetLocationY(source) + dist * Sin(angle * bj_DEGTORAD) return Location(x, y) endfunction Tell me, what leaks here? It certainly doesn't leak a handle (as in the handle-array-entry, not the object itself)...As it doesn't assign the returned location to a local variable...and the only other location in this function is defined in the header, and considering this thread (and the tests behind it) confirm that header-defined locals don't need to be de-referenced.... So what is the problem, exactly?. If you look at the other BJ location functions, they all work with X/Y, then just return a brand new, fresh location (non-referenced). I even wonder if at the time I feared PolarProjectionBJ, that perhaps I just wasn't catching the return/parameter and destroying them... Anyways, if you're still certain that it leaks, i'll be interested to do tests with it, but otherwise, i don't think i'm gonna bother, considering the innocency in these 5 lines of code. Cubasis |
| 04-01-2004, 07:52 AM | #5 |
You're right, it doesn't leak. I thought it was using a local variable for the location :) or maybe I forgot :P |