- Joined
- Feb 18, 2004
- Messages
- 394
You don't have to null temporary globals like those. It only really matters with globals who's values will not change it a long time or possibly at all, or locals.
Yes, for theEarth-Fury said:(There are some bugs in this. I think its unit states, I forget.)
IsUnitType
native. The thing is, booleans are meant to be either 0 (false
) or 1 (true
). IsUnitType
, on the other hand, sometimes returns boolean values labeled 64 or things like that. The thing with Jass is it evaluates comparisons in a weird way.return IsUnitIllusion(someUnit)
// The line above will evaluate the returned value of IsUnitIllusion.
//If the value is anything other than 1 (true), the function will return false.
return IsUnitIllusion(someUnit)==true
// The line above will evaluate the returned value of IsUnitIllusion.
// Then a boolean comparison will be made with the returned value
// and the true value. In this case, the function will return true if
// IsUnitIllusion(someUnit) returns anything except 0 (false).
return IsUnitType(someUnit, SOME_BUGGY_UNIT_TYPE_CONSTANT)
// The problem with the above line is sometimes, IsUnitType returns
// true values which are not 1, but 64 or something like that. That
// means that, without the ==true, these boolean comparisons will
// ineffectively return false.
integer
real
code
boolean
string
// The ones above are Wc3 native types. They do not have to be nulled
// Only handles have to be nulled, then again, not ALL handle extensions.
// All of the other types whose functions return constant values:
player // is a handle.
boolexpr // is a handle.
race // is a handle...
// etc...
HINDYhat said:JASS:// All of the other types whose functions return constant values:
Ok, variables contain a small amount of information (i think 8 bytes or so), and things like reals, integers, booleans, etc. are numbers that represent something in binary directly
While, handles are large pieces of information, and the variables simply point to them
When you null a variable, it simply clears the 8 bytes of information in them, but the "destroy" functions eliminate the whole handle (not the variable though!)
So, wouldn't you want to null the player variable, because it is pointing to the player handle, and would leave that tiny little variable leak??? (if let's say it was a local)
set SomeUnit = CreateUnit()
set SomeAlsoUnit = SomeUnit
function Abc takes nothing returns nothing
local unit u = CreateUnit(...)
endfunction
call Abc()
) you create a new unit, which is just fine. However, you also increase the reference count for the unit. Because of a bug, the reference count is not automatically decreased for the created unit once the function is done. The pointer also ceases to exist once the function is done, as the variable that held it no longer exists! (Or rather, the instance of that variable that held the actual pointer no longer exists.)function Abc takes nothing returns nothing
local unit u = CreateUnit(...)
set u = null
endfunction
set
statement works properly in that it will decrease the reference counter.player
s, as the function Player(whateverNumber)
will always return a pointer to the same handle for the same input. You also can not destroy players, so it really doesn't matter what the reference count is.