[JASS] local variable destruction

[maskedpoptart]

quick question: are local variables destroyed automatically, once the function is done executing? i would believe so. if not, i'll have to manually destroy/remove stuff, in the end of the function, to keep it from leaking...

 

[Soga-]

Nothing is automatically destroyed. You must manually invoke the "DestroyGroup", "RemoveLocation" and so on forth.

Additionally, for any local variable that is of type handle or extends handle, you must set them to null at the end of your functions.

 

[maskedpoptart]

out of curiosity, what happens when you do not set variables (of types that extend handle) to null at the end of the function? (this may be the cause of some of my bugs.) local variables can't be used by other functions anyway, right?

 

[GhostWolf]

Local variables are only declared inside their scope.

And not setting pointers to null (point to 0), the next time you use them, seeing as you destroyed what they pointed to - they can point to something else, which can mess your program.

Now that I've said that I am not really sure it's necessary to set pointers to null at the end of their scope as they are deleted anyway... anyone knows more then me?

 

[HINDYhat]

Do they actually stop pointing to that object? You should try H2I on a handle, then remove it, and do it again.

 

[Element of Water]

It just messes up the handle stack. Say you created a local location l, and it's handle id was 0x100000+1 (in case you're wondering, 0x100000 is the hex number at which the handle stack starts), then you nulled it at the end of the function, then ran the function again before creating any more handles, the new local variable's handle id would also be 0x100000+1, whereas if you hadn't nulled it, the new location's id would be 0x100000+2. It's no big deal, it doesn't cause any memory leaks, but the problem comes when the handle stack reaches its limit. I'm not sure what happens then, but it can't be good.

I hope I explained it well enough, feel free to ask questions if you didn't understand something.

 

[Saishy]

The guy who have an starcraft airship as avatar told me that not setting pointers to null will not free the variable memory space, since they are kept because they still point to something, even if that something was destroyed.

http://www.hiveworkshop.com/forums/f269/question-about-groups-116103/

 

[Element of Water]

What Soga said was essentially the same as what I said. He just put it a different way.

 

[Dr Super Good]

Acording to current belief, No local leaks data. The memory the local used to store a value is removed when the fnction ends. What can happen thou is that an object a local was refererencing leaks.

This happens when you do not destroy it and it can no longer be easilly fetched to be destroyed. However due to bad garbage collectiors in the WC3 engine, what can happen is an object still things a local is referencing it when it actually is not, even if the object is destroyed and so blocks up a handle index permantly.

Thus you only need to null local handles that use values that are not constant or not refrencable. Eg you do not need to null a local player as there are only 16 of them which all can be fetched via triggers (return the same handle index) thus it does not mater if they can never be freed up.

Equally, if you use object recycling, they do not need to be nulled as the objects are constantly reused and never destroyed so their indexes never need to be recycled.

 

[maskedpoptart]

thanks for the help, guys. i understand it now.

but what is object recycling and how do you do it?

 

[Soga-]

Object recycling is simply where you reuse the object over and over. For example, consider an unit group. To recycle an unit group would be to use a global unit group and simply clear it, as opposed to destroying it.

Or timers; you could recycle timers by just pausing them and then restarting them at a later time as opposed to destroying a timer and creating a new one.

 

[maskedpoptart]

errr one last question:
for local variables like locations, forces, and groups that leak, can you just "call RemoveLocation(point)" or do you have to also "set point = null?" (why?)

if you have to do both, what order do you need to do it in? (why?)

 

[Justify]

First destroy it, then null it.
A local variable is never a location or a group. It's a pointer to a group, a reference to it. If you give a pointer a new value (null) it's not possible to destroy the "old" handle (unless you have another variable pointing at it, but that should be clear).
First you need to destroy it, for example "call RemoveLocation(tempLoc)" removes the location at which "tempLoc" is pointing at. Now you fixed the leak, but the variable still has the reference to a destroyed object, so you should null it

 

[Shadow Daemon]

  // removing the actual object via reference
  call RemoveLocation(loc)
  call DestroyGroup(grp)

  // clearing local variable reference to already removed object
  // for correct work of handle mechanism
  set loc = null
  set grp = null

 

[maskedpoptart]

set udg_movePoint[pickedPlayerId] = lastCreatedUnitPosition
...
call RemoveLocation(lastCreatedUnitPosition)
set lastCreatedUnitPosition = null

so if i'm understanding what Justify said correctly, i should not RemoveLocation(lastCreatedUnitPosition) in the above case because it will cause udg_movePoint[pickedPlayerId] to point to nothing. this would keep me from using the value of udg_movePoint in future triggers.
right?

 

[Element of Water]

I believe so, yes.

 

[Soga-]

First destroy it, then null it.
A local variable is never a location or a group. It's a pointer to a group, a reference to it. If you give a pointer a new value (null) it's not possible to destroy the "old" handle (unless you have another variable pointing at it, but that should be clear).
First you need to destroy it, for example "call RemoveLocation(tempLoc)" removes the location at which "tempLoc" is pointing at. Now you fixed the leak, but the variable still has the reference to a destroyed object, so you should null it

No, if a variable is local, that doesn't mean it's a pointer. You're thinking of a handle variable type, which is a pointer.

The local keyword just indicates the scope of the variable and nothing more than that. However, there IS a handle index leak issue (which is explained elsewhere if you use the search engine), so you have to null local handle variables.

But locals such as real, integer, string... basically anything that's not a subtype of handle, you don't have to null.

 

[Saishy]

I was looking to some spells and those constants...

That means they will always use memory even if you never use the spell?

 

[Soga-]

What do you mean?

 

[Saishy]

What do you mean?

They will always take memory space?

 

[Soga-]

What are "they"?

 

[Saishy]

What are "they"?

constant variables lol

like:

globals
     private constant integer = 'Avul'
     private constant group = Ikillyou
     private constant unit = asyousleep
endglobals

So, even if I never use the spell, or just a few times, they will take memory space?

 

[PurplePoot]

They will take 4 bytes.

If you care about 4 bytes, then you will go insane very very quickly.

 

[HINDYhat]

And they're inlined anyway if you use Vex's optimizer I believe.

 

[Saishy]

They will take 4 bytes.

If you care about 4 bytes, then you will go insane very very quickly.

If you have 50 heroes, 4 spell for hero, that is 800 bytes!
Almost an entire MB!

 

[PurplePoot]

*Almost an entire kilobyte. 0.781kB to be exact, or 0.00076mB.

Besides, if you have fifty heroes, you're stupid anyways.

 

[Saishy]

*Almost an entire kilobyte. 0.781kB to be exact, or 0.00076mB.

Besides, if you have fifty heroes, you're stupid anyways.

Lol why?

 

[Soga-]

Because you would be the developer of DotA.

 

[Saishy]

Because you would be the developer of DotA.

He haves 94...

I didn't got it anyway o.o

 

[PurplePoot]

Because 50 heroes is way too much for... well, anything? If you made 50 heroes, you have evidently rushed them. Besides, there's a point at which there is just too much choice, and it overwhelms people.