Condition Leaks ??

03-19-2007, 08:24 PM

Ok, so leaking in functions is all good and fine..simple and relatively straightforward.

However, no one ever looks or cares about the conditional "functions" (since they are, after all, functions themselves). Never, EVER have I see anyone worry about the handles extended by native calls (or even, god forbid, a BJ function call).

Has nobody ever really thought about it? Or are conditional functions executed with a special "native" parameter that automatically deallocates any handles that are extended as a result of its operation?

In any case, just curious.

03-19-2007, 09:05 PM	#2
SFilip	What exactly are you talking about? Trigger Conditions? Boolexprs? An example of this leak perhaps?

03-19-2007, 09:53 PM	#3
WNxCryptic	Trigger conditions. And its not a leak in particular, but the concept that those trigger conditions themselves may leak.

03-19-2007, 11:06 PM

FatalError

Quote:

Originally Posted by WNxCryptic

Trigger conditions. And its not a leak in particular, but the concept that those trigger conditions themselves may leak.

You mean this?

JASS:

function SomeTrigger_Conditions takes nothing returns boolean
return IsUnitIllusion(GetEnumUnit())
endfunction

Actually, that doesn't leak. I may be wrong on this, but I'm about 98% sure that if you pass a function that returns a handle as an argument, it doesn't leak, because arguments in WC3 have some sort of garbage collector. So it doesn't leak.

03-19-2007, 11:39 PM	#5
SFilip	Ah I think I understand...you're asking if there is a memory leak in a function used as a condition for some trigger? A function used this way will run every time the event triggers so yes, it can leak and it is very important to free any memory allocated in it - the game pretty much can't do this on it's own.

03-19-2007, 11:45 PM	#6
Earth-Fury	Im rather sure that WC3 isn't smart enogh to do effective garbage collection at all, let alone in one specific area. So destroying unused handels within conditional functions is probobly a good idea.

03-20-2007, 12:05 AM	#7
WNxCryptic	lol..that's what I thought, I guess its minuscule enough that no one really ever worries about it. I had to satisfy my curiosity though :D

03-20-2007, 12:08 AM	#8
FatalError	Ah, my bad, I was reading this topic and I misunderstood the part about Wrapper Functions. Then that's stupid. Any function that returns a handle leaks a bit, am I right?

03-20-2007, 12:49 AM

Earth-Fury

Quote:

Originally Posted by FatalError

Ah, my bad, I was reading this topic and I misunderstood the part about Wrapper Functions.

Then that's stupid. Any function that returns a handle leaks a bit, am I right?

Any function that reurns a handle that hasnt had all variables referancing it set to null / another value leaks. thats how i understand it.

03-20-2007, 12:58 AM	#10
botanic	I did a test conditions do leak you need to use it then functions to avoid them... :(

03-20-2007, 12:58 PM	#11
WNxCryptic	Botanic, for future reference...use punctuation in your posts.

03-21-2007, 03:04 AM

#12

Pyrogasm

Quote:

Originally Posted by WNxCryptic

Botanic, for future reference...use punctuation in your posts.

Most definitely.

03-21-2007, 03:15 AM

#13

moyack

Well... I'm used to destroy and null all the handles in the condition functions, and I haven't had any side effects for doing that, so I consider healthy doing a memory cleaning in that functions too.

Testing filter:

function Attacking_Script_IsStructure takes nothing returns boolean
    local unit u = GetFilterUnit()
    local boolean b1 = IsUnitType(u, UNIT_TYPE_STRUCTURE) == true
    local boolean b2 = GetUnitLevel(u) == 0
    set u = null
    return b1 and b2
endfunction

As an advantage, I gain readability in the code :)