[JASS] Are function params also pointers?

[Bribe]

function set_unit takes unit u returns nothing
    call SetUnitUserData(u,1)
endfunction

Should unit u die, will its handle index be recycled or does the function parameter still point to it?

Also, not so much relevant, but I don't want to do a double-post - can I set a parameter within a function like this?:

function new_trig takes trigger t returns trigger
    set t = CreateTrigger( )
    return t
endfunction

 

[Berb]

Well it is a pointer but the memory references are recycled I believe.

Should unit u die, will its handle index be recycled or does the function parameter still point to it?

The actual handle reference of the unit is not recycled until the unit has been removed from the game, at which point any variable references to that unit would become null.

Also, not so much relevant, but I don't want to do a double-post - can I set a parameter within a function like this?:

Yes.

 

[Bribe]

So local unit doesn't typically need to be nulled since it's nulled by default when the unit is removed from the game?

But timers, triggers, groups, etc. don't function the same way, from what I've read.

However, not needing to null a unit would improve gameplay performance for some projects I'm working on.

 

[Berb]

Well no it isn't set to null automatically, but I think that is what it will return anyway. The value still must be set to null in order for the handle reference to be recycled.

 

[Bribe]

Hopefully the parameters are at least defaulted to null at the end of the function as you say (I don't really see why they wouldn't be since I've never seen or heard of anyone setting parameters to null)

 

[PurgeandFire]

Well no it isn't set to null automatically, but I think that is what it will return anyway. The value still must be set to null in order for the handle reference to be recycled.

^This is what I believe as well.

It really just depends on whether or not it is permanent. If it is permanent, you shouldn't have to worry about nulling the pointers. (although, in essentially all cases [except for possible random extremely rare retarded cases] it shouldn't matter if you do null it when you don't need to)

That's why sometimes it isn't needed to null the pointers, since its id never needs to be recycled. (TimerUtils -> no need to null timers, they are recycled, Groups -> recycled as well, just a global, triggers -> don't need to, except for dynamic triggers, and those sometimes have recycling methods as well, players -> never destroyed, no need to null)

Anyway, setting it to null might result in a minimal speed loss, but it doesn't really take up as much as you might think. According to my benchmarks, setting a variable to null averages at about 16% faster than DoNothing(). =)

 

[Berb]

Parameters do not need to be set to null. The reason for that being the memory necessary for function parameters is probably allocated already, and constantly recycled. I'm not entirely sure there may be a more correct answer than this.

 

[Bribe]

I think the outcome of what this means is that it would be more efficient to utilize:

function foo takes unit u,unit v,unit w,unit x returns nothing
    // effects
endfunction

Than to try:

function bar takes nothing returns nothing
    local unit u
    local unit v
    local unit w
    local unit x
    // effects
    set u = null
    set v = null
    set w = null
    set x = null
endfunction

Because that way you don't have to null so many variables.

 

[PurgeandFire]

I guess, but wouldn't an external function call be slower than local variable declarations/nullings? (Well, I guess it depends on the amount of locals used)

 

[Bribe]

You said so yourself that call DoNothing() is only 16% slower than set var = null. By that rule, using variables is going to be dynamically faster with parameters instead of locals.