Question about leaks in JASS

12-16-2009, 04:33 PM

I'm sorry if this has been asked before but i've searched and could not find the answer i was looking for. I'm trying to do a conversion of all triggers in a map that need to be multi-instantiable.

Heres what i've got in JASS:

JASS:

//Minus 1 from Heroitemcount[i] whenever a hero loses an item.
function ItemCounterMinus_Copy_Actions takes nothing returns nothing
    local integer i = ( GetConvertedPlayerId(GetOwningPlayer(GetTriggerUnit())) - 2 )
    set udg_HeroItemCount[i] = ( udg_HeroItemCount[i] - 1 )
endfunction

//===========================================================================
function InitTrig_ItemCounterMinus_Copy takes nothing returns nothing
    set gg_trg_ItemCounterMinus_Copy = CreateTrigger(  )
    call TriggerRegisterAnyUnitEventBJ( gg_trg_ItemCounterMinus_Copy, EVENT_PLAYER_UNIT_DROP_ITEM )
    call TriggerAddAction( gg_trg_ItemCounterMinus_Copy, function ItemCounterMinus_Copy_Actions )
endfunction

As a reference Heres the original version, converted from GUI.

JASS:

function Trig_ItemCounterMinus_Actions takes nothing returns nothing
    set udg_TempUnit = GetTriggerUnit()
    set udg_TempPlayer = GetOwningPlayer(udg_TempUnit)
    set udg_TempInt = ( GetConvertedPlayerId(GetTriggerPlayer()) - 2 )
    set udg_HeroItemCount[udg_TempInt] = ( udg_HeroItemCount[udg_TempInt] - 1 )
endfunction

//===========================================================================
function InitTrig_ItemCounterMinus takes nothing returns nothing
    set gg_trg_ItemCounterMinus = CreateTrigger(  )
    call TriggerRegisterAnyUnitEventBJ( gg_trg_ItemCounterMinus, EVENT_PLAYER_UNIT_DROP_ITEM )
    call TriggerAddAction( gg_trg_ItemCounterMinus, function Trig_ItemCounterMinus_Actions )
endfunction

Im worried the JASS version leaks as i am calling natives within natives. =/
(Leak Check v3.1 detects leaks whenever i call natives in natives in GUI.)

On a sidenote, does vJASS or Zinc have leak checking capability?
I havn't had a chance to try them out yet. Still very new to JASS.

12-16-2009, 04:37 PM	#2
Anitarf	The new version has no leaks. It is also no more multi-instanceable than the old one.

12-16-2009, 05:09 PM

sPyRaLz

Quote:

Originally Posted by Anitarf

The new version has no leaks. It is also no more multi-instanceable than the old one.

Ah alright, thanks a lot for the feedback about the leaks =)

I think i might have misunderstood multi-instancing though.

According to what I've read here and there around the forums, I'm under the impression that multi-instancable functions are useful when there is a risk of a bug occurring if two players
fire the trigger at the same time.

With the GUI, for the trigger in question, chances seem very low. Lets say two players fired the trigger at the same time, it would mess up the variables udg_TempUnit,ud_TempPlayer and udg_TempInt.

Since the JASS version uses local integer i instead, there is no risk of this happening,
doesnt that mean its multi-instancable?

12-16-2009, 07:23 PM

Anitarf

Quote:

Originally Posted by sPyRaLz

With the GUI, for the trigger in question, chances seem very low. Lets say two players fired the trigger at the same time, it would mess up the variables udg_TempUnit,ud_TempPlayer and udg_TempInt.

Since the JASS version uses local integer i instead, there is no risk of this happening,
doesnt that mean its multi-instancable?

The thing is, what you described can not happen. Even if the trigger fires twice "at the same time", it won't actually execute in parallel. The two instances will just go to the stack and then be executed in order. The only way trigger A can interrupt trigger B in the middle of execution is if trigger B has a wait action (pretty obvious) or if trigger B has an action that causes trigger A's event to run (like trigger B doing damage to a unit and trigger A using the "unit dies" event). Neither of these two cases applies to your example, so it is multi-instanceable regardless of whether you use globals or locals.

The real problem with multi-instanceability are spells that do not have an instant effect, but persist for a longer duration, usually using timers to execute some of their code periodically or with a delay. The GUI triggers are not well suited for handling that (though it is still possible to do).