[JASS] GetFilterUnit()

[mecatronic]

Is there a way to make it don't leak?

I think it can't be set to a local unit variable because it's called inside the randon group function..

 

[HINDYhat]

GetFilterUnit() does not leak... Who said it did?

 

[mecatronic]

actually no one, i assumed it.

I thought every handle that's not set into a variable would leak. Am I wrong?

 

[HappyTauren]

you are. Handles are like integers (ie pointers in VB)
Also, locations leak,for example, because you cant reference them any logner if you dont set them to variable. Handles can be referenced and thus can't leak. It is highly advised to null local handles in jass scripts though.

 

[aznricepuff]

uhhhh...locations ARE handles:

type location extends handle

And handles DO leak. The entire point of nullifying handles is to prevent memory leaks.

In JASS, any variable type tht is not a(n): integer, real, boolean, string,
is a handle. (the four types listed above are hardcoded natives)

Since all handles can leak, make sure to nullify all local variables that don't belong to one of the above four types once you're done using them.

By the way, I'm not sure if GetFilterUnit() leaks. I just avoid FOR loops altogether so I never have deal with it.

 

[Need_O2]

Leak != Lag
!!!! Learn Jass !!!!

there is a no way to make unit variable leak anyway
(may be if you make decay time unlimited and kill unit without remove and make it does decay )

Leak: Causing an unused value to fill your memory. It can be locations-unitgroups-special effects that you cant see but not destroyed (they are still used when they are visible)
For example you create a group
it lasts forever unless you dont destroy it
Groups - Locations - Ligthning Effects - Timers - Special Effects - Forces etc etc etc etc are objects just like units and they will exist until they get destroyed
and they will hold some memory while they are existing for sure

 

[HINDYhat]

And handles DO leak. The entire point of nullifying handles is to prevent memory leaks.

Not all handles

In JASS, any variable type tht is not a(n): integer, real, boolean, string, is a handle. (the four types listed above are hardcoded natives)

You forgot the 'code' type.

By the way, I'm not sure if GetFilterUnit() leaks.

It doesn't leak. What leaks is if you do something like this:

local unit u=GetFilterUnit()
return GetUnitTypeId(u)=='LOLZ'

Which isn't nulling the local unit.
And anyway, I'm not even sure of the cause of the non-nulling leaks. I'm pretty sure it's just the handle ID that doesn't get recycled, so when you use something like I2S(H2I(somehandle)), a new string will be created, and thus leaking in strings. So I think that if you don't use gamecache, you don't even have to null locals (but I'm not sure... makes sense though).

I just avoid FOR loops altogether so I never have deal with it.

For loops are awesome. ForGroup is one of the best natives ever.

 

[PurplePoot]

And handles DO leak. The entire point of nullifying handles is to prevent memory leaks.

Not really. That has to do with the pointer, not the handles themselves.

For loops are awesome. ForGroup is one of the best natives ever.

You know what he meant

 

[PandaMine]

There are 2 types of leaks, pointer leaks and handle leaks.

The pointer leaks make the biggest difference and that usually consists of not removing dummy units when your finished, not destroying effects when your finished, not destroying text tags when your finished, not destroying locations when your finished etc.

The other type of leak is pointer leak. Although the seriousness of this type of leak is debatle, often it goes un-noticed unless you use certain systems that implement the H2I - 0x100000 method for storing data or you somehow manage to leak over one million pointers

 

[Drone]

It doesn't leak. What leaks is if you do something like this:

local unit u=GetFilterUnit()
return GetUnitTypeId(u)=='LOLZ'

Which isn't nulling the local unit.

I agree that initializing variables, nulling pointers/handles etc, when not used further, is good programming practice. However the usefullness of nulling local handles at the end of a function I do question. Jass locals are not static locals. I have not seen one case in Jass where a local would retain its value in between function calls. They're on the stack and the stack space used is released after a function call. Therefore that one reference to the object is gone.

If you don't null that local handle, but do destroy the object, do you really think the local handle will still use memory? I don't, since its local and the stack memory its on will be released after the function call.

 

[Silvenon]

Leak != Lag

Leak -------> Lag --------> Massive lag ------> Crash

The only problem of leaks are that they lag.

 

[HappyTauren]

Hmm I have seen some BJ functions that don't null local handles. If that is how blizzard does it, than it should be right?

 

[HINDYhat]

No. Blizzard is wrong most of the time -.-

 

[Silvenon]

I thought we made that clear already

They also destroy boolexprs.

 

[HINDYhat]

They also destroy boolexprs.

Fixed:
They also destroy nothing.

 

[Drone]

Fixed:
They also destroy nothing.

What do you mean by that? Are you suggesting they don't clean up?
If that's the case then open some campaign maps of Blizzard. They do remove/destroy objects if they can leak. So its not like they do absolutely nothing against it.

 

[HINDYhat]

O RLY? I thought I remember opening up some campaign maps a while ago and laughing at the non-removed handles. Ah well... nevermind then

 

[Silvenon]

oh really = orly
ya really = yarly

 

[HINDYhat]

I think we all know that.

ANYWAY, enough off-topic spam. Back on subject!

 

[Silvenon]

Yeah, we should stop spamming.....

Back on subject! ....... GetFilterUnit() doesn't leak, that's all there is to the subject