Help: Cleaning up a JASS And condition.

01-26-2007, 09:22 PM

The following JASS function is an AND condition:

JASS:

function Trig_MOVEMENT_Controller_JASS_Func006Func011C takes integer CV returns boolean
    if ( not ( udg_MoveCalcsR[( ( 4 * CV ) + 1 )] == udg_MoveCalcsR[( ( 4 * CV ) + 3 )] ) ) then
        return false
    endif
    if ( not ( udg_MoveCalcsR[( ( 4 * CV ) + 2 )] == udg_MoveCalcsR[( ( 4 * CV ) + 4 )] ) ) then
        return false
    endif
    return true
endfunction

I'm trying to remove a function call from this line:

JASS:

if ( Trig_MOVEMENT_Controller_JASS_Func006Func011C(CV) ) then

Is this possible and if so, how?

01-26-2007, 09:54 PM	#2
Dalten	Also, do local locations, special effects, etc need to be destroyed at the end of a trigger or does the fact that they're local mean they get cleared out of memory at the end of the trigger life?

01-26-2007, 09:58 PM

The)TideHunter(

Yes.
Remove that function, and instead of:

JASS:

if ( Trig_MOVEMENT_Controller_JASS_Func006Func011C(CV) ) then

Use:

JASS:

if(udg_MoveCalcsR[4*CV+1] != udg_MoveCalcsR[4*CV+3] and udg_MoveCalcsR[4*CV+2] != udg_MoveCalcsR[4*CV+4])then

EDIT:

Quote:

Originally Posted by Dalten

Also, do local locations, special effects, etc need to be destroyed at the end of a trigger or does the fact that they're local mean they get cleared out of memory at the end of the trigger life?

Because they are locals dosent neccersarily mean they need to be destroyed at the end of the function, but the variable does have to be.

Example:

JASS:

    local effect e = CreateEffect(...)
    call DoStuffWithEffect(e)
    set e = null

We dont have to destory the effect, but we do need to destroy the variable, which is setting it to null. It removes the pointer in the variable.

But if we do that, we cant get the pointer back later, so if your not going to use the effect, you might aswell destroy it.

So to answer your question. No, the handle's do not need to be destroyed, but the variables does.

01-26-2007, 10:05 PM	#4
Dalten	Thank you sir, rep inc.

01-26-2007, 10:06 PM	#5
Dalten	One more thing, this trigger is a periodic trigger so the local variable will get endlessly reused. Is it worth it in this case to null the variables?

01-26-2007, 10:15 PM	#6
Rising_Dusk	It's always worth it to nullify datatypes that extend handle at the end of functions whenever you can.

01-26-2007, 10:16 PM

The)TideHunter(

You should null the variables in every case, or its a small memory leak.
You should definatly null them if its periodic, or you will leak them everytime it runs.
Remember, when you run the trigger because its periodic, it dosent use the old local variable, it makes a new one! So if you dont destroy the old one, you will just have heaps and heaps of memory thats leaked.
The only variable you should be carful about nulling is a timer, as its caused problems in the past, its called the "timer set to null bug", you could search for it if you wanted to know more, but just aviod that.

Remember, once you null, you cant get back the handle the variable was pointing too, and if you dont null, you will leak memory. Its tough, but you have to do it xD. Also remember that when a trigger sees the "local variabletype variablename" code, it will create a fresh new variable, and not touch the old one.
This is crappy, Blizzard should have included a garbage collector but dident, so we have to do it manually.

EDIT:

Quote:

Originally Posted by Dalten

Thank you sir, rep inc.

Thanks =).

01-26-2007, 10:40 PM	#8
Dalten	I don't fully understand handles so forgive me if this is a stupid question: Do simple types like integers, reals, etc have to be null'd out or set to 0 as well?

01-26-2007, 11:22 PM	#9
Alevice	Nope. Integers, reals, and strings don't have to be nulled. Well, you can null the strings, but it is pointless, for in reality it does not much.

01-27-2007, 10:16 AM

#10

The)TideHunter(

Handles are all types that are not; string; integer; boolean; real or code.
Like units, destructables, players, units, effects.
Heres some info from common.j:

JASS:

type event              extends     handle  // a reference to an event registration
type player             extends     handle  // a single player reference
type widget             extends     handle  // an interactive game object with life
type unit               extends     widget  // a single unit reference
type destructable       extends     widget
type item               extends     widget
type ability            extends     handle
type buff               extends     ability
type force              extends     handle
type group              extends     handle
type trigger            extends     handle
type triggercondition   extends     handle
type triggeraction      extends     handle
type timer              extends     handle
type location           extends     handle
type region             extends     handle
type rect               extends     handle
type boolexpr           extends     handle
type sound              extends     handle
type conditionfunc      extends     boolexpr
type filterfunc         extends     boolexpr
type unitpool           extends     handle
type itempool           extends     handle
type race               extends     handle
type alliancetype       extends     handle
type racepreference     extends     handle
type gamestate          extends     handle
type igamestate         extends     gamestate
type fgamestate         extends     gamestate
type playerstate        extends     handle
type playerscore        extends     handle
type playergameresult   extends     handle
type unitstate          extends     handle
type aidifficulty       extends     handle

type eventid            extends     handle
type gameevent          extends     eventid
type playerevent        extends     eventid
type playerunitevent    extends     eventid
type unitevent          extends     eventid
type limitop            extends     eventid
type widgetevent        extends     eventid
type dialogevent        extends     eventid
type unittype           extends     handle

type gamespeed          extends     handle
type gamedifficulty     extends     handle
type gametype           extends     handle
type mapflag            extends     handle
type mapvisibility      extends     handle
type mapsetting         extends     handle
type mapdensity         extends     handle
type mapcontrol         extends     handle
type playerslotstate    extends     handle
type volumegroup        extends     handle
type camerafield        extends     handle
type camerasetup        extends     handle
type playercolor        extends     handle
type placement          extends     handle
type startlocprio       extends     handle
type raritycontrol      extends     handle
type blendmode          extends     handle
type texmapflags        extends     handle
type effect             extends     handle
type effecttype         extends     handle
type weathereffect      extends     handle
type terraindeformation extends     handle
type fogstate           extends     handle
type fogmodifier        extends     handle
type dialog             extends     handle
type button             extends     handle
type quest              extends     handle
type questitem          extends     handle
type defeatcondition    extends     handle
type timerdialog        extends     handle
type leaderboard        extends     handle
type multiboard         extends     handle
type multiboarditem     extends     handle
type trackable          extends     handle
type gamecache          extends     handle
type version            extends     handle
type itemtype           extends     handle
type texttag            extends     handle
type attacktype         extends     handle
type damagetype         extends     handle
type weapontype         extends     handle
type soundtype          extends     handle
type lightning          extends     handle
type pathingtype        extends     handle
type image              extends     handle
type ubersplat          extends     handle

They are all handles. Not all of them extend a handle, but for example gameevent extends eventid and eventid extends handle, so they are still handles.

All of those should be nullified, (maybe except for timers).
The atomic types and code dont need to be nullified or removed.
Its the pointer that uses memory (atomic and code types use memory too, but not on pointers), look at this:

JASS:

    local unit u = SomeUnit

When you set a variable to a handle, it creates a pointer, the pointer uses memory.
If you dont destroy the pointer, then its going to keep the memory there forever.
So at the end of your function, just add a line that sets to null. You dont neccerarily need to put it after you'v finished using it, but you could.

Example:

JASS:

    local unit u = MyUnit
    call DoStuffWithUnit(...)
    call RemoveUnit(u) // Remove the Unit
    set u = null // Remove the pointer
    // The handle AND the pointer has been removed, you know you are not leaking anything