Questions about coding and memory leaks

[The Dark One]

Correct me if I am wrong, every function that defines a handle (player, unit, unit group,…) will leak if they aren’t assigned to a variable (local or global) and removed later.

Reassigning a value to a certain variable (handle type) will not overwrite the previous value and the previous value will leak and thus you have to destroy/Remove the old value before you assign a new one to the variable.

What is the code to destroy unit variables? It isn’t removeunit because that will remove the unit and not just the value stored in the variable.
Do I need to remove a unit that is killed?
I have a unit group stored in a hashtabel and I have the following action in one of my triggers:

Trigger:

Unit Group - Pick every unit in Casters and do (Actions)

Loop - Actions

Set TempHandle2 = (Picked unit)
Unit Group - Pick every unit in (Load VisualEffectgroup of (Key TempHandle2) in HashtableJ) and do (Unit - Kill (Picked unit))

Do I have to do this (assign the handle of the picked unit from the first Unit Group action so as not to use two (Picked unit) in the same line) or will the editor know the difference and be smart enough and not get confused over it?

Trigger:

Unit Group - Pick every unit in (Load VisualEffectgroup of (Key (Picked unit)) in HashtableJ) and do (Unit - Kill (Picked unit))

Thanks in advance.

[Bribe]

Trigger:

Unit Group - Pick every unit in (Load VisualEffectgroup of (Key (Picked unit)) in HashtableJ) and do (Unit - Kill (Picked unit))

Perfectly valid.

The reason we tell GUI users to store variables are for locations and groups - the two most prominent leaks for GUI users.

There is no reason to store a unit-variable if you only plan to reference it once, in fact, that's quite wasteful. That's like:

JASS:

function foo takes nothing returns returns unit
    local unit u = GetTriggerUnit()
    return u
endfunction

Not only is that pointless, but it brings up another concern: handle leaks. Those are different from the ones like location/group leaks, and I won't delve into that realm because I don't think that's addressing your question.

You do not need to remove a unit when it dies. After the 60-second corpse decay period (if it's not a hero), the unit will cease to exist.

If the unit is a hero-unit and you don't need it any more, yeah, remove it from the game so that it won't consume a hero-icon.

[TheKid]

Those are different from the ones like location/group leaks, and I won't delve into that realm because I don't think that's addressing your question.

Well it's not so much a "handle leak" as a pointer reference problem. The handle indexes of objects in the game are not recycled (though, some are, such as images) until all the references to that object have been cleared. This means that if you forget to set a unit variable to null then the handle index that the unit occupies will not be recycled (at least this is to the best of my knowledge).

You do not need to remove a unit when it dies. After the 60-second corpse decay period (if it's not a hero), the unit will cease to exist.

Actually it's about 88 seconds; the values are changeable in the game-play constants. It depends on the type of decay (for example, buildings have a different decay-time than units).

[Anitarf]

Originally Posted by TheKid

Well it's not so much a "handle leak" as a pointer reference problem. The handle indexes of objects in the game are not recycled (though, some are, such as images) until all the references to that object have been cleared. This means that if you forget to set a unit variable to null then the handle index that the unit occupies will not be recycled (at least this is to the best of my knowledge).

That is correct. Note that global variables are not much of a problem because they will be set to a different value eventually as the map keeps running. Local variables, on the other hand, have a bug: when a function finishes, it will not decrement the reference counter on any handles that local variables point to. As a result, when a handle (such as a location, group, unit, effect) is removed from the game, its handle address will not get recycled because the game will still think there are variables pointing to it. This is why it is important to set local variables of the handle type to null before a function finishes execution.

Since you can't use local variables in GUI to begin with, this shouldn't really affect you; the problem is that several BJ functions (functions written by Blizzard for GUI) have this leak.

[The Dark One]

So what do I do when I want to point to a unit in GUI?
I use GUI pointers (Summoned unit, triggering unit, dying unit,…) without fear of memory leaks?
I assign them to a global variable and set that variable to null once I am done with it?
I stop using GUI and start using Jass? (Not available at this time).

I didn’t get that unrecyclable pointer thing there; can anyone expand that for me?
I really want to start coding with Jass, but with only knowledge of functions and how to call them, I feel like a deaf guy in a celebration and get discouraged and run to GUI, but I am aiming to become a coder of Vexorian’s level (way over my head but if I want to become the best than I should be aiming for the best) and would like to start as soon as possible.

[Tot]

1) yup
2) depends on type, groups/locations/rects/effects should be destroyed
3) best way...get you jngp from this site...

as long there is one pointer (variable that holds) to the object, it's id won't be reused
jass is not that har (esp vJass), you mainly need the functionnames and parameters...the rest is intuitive (function ... takes ... returns ... endfunction)

[DioD]

there is no need of leakseeking if you using GUI, this is completely impossible to prevent leaks in many cases.

[The Dark One]

DioD, I heard of such thing, can you make an example (or a general guide line to avoiding them, I am sure I can code my way around some of these cases).

Since GUI is leaking regardless of what we do than why is it allowed in spell contests and hell we even have GUI spells in the resources section!

[Anitarf]

Originally Posted by The Dark One

Since GUI is leaking regardless of what we do than why is it allowed in spell contests and hell we even have GUI spells in the resources section!

If there are any GUI spells in the resource section then they are a remnant of a more primitive time. No such spell would get accepted today. As for contests, the goal there is to make an awesome spell, which often coincides with but does not necessarily mean an awesomely coded spell.

[The Dark One]

Then we have a problem here.
There are people out there who say that you can GUI a decent spell while you (the elite coders of the moding society) say that no one should use that piece of trash.
Now I read the tutorial section and find tons of GUI triggering tutorials and how to remove memory leaks and how to MUI spells in GUI and then I enter the resources section and find GUI spells and I say to myself: “hay, GUI isn’t as bad as some say because they accept it” and I end up learning, and getting addicted to, GUI.

Instead, the administrators should remove all the GUI tutorials and all the GUI spells and declare GUI none efficient coding method and that every self respecting coder (or coder want to be) should learn Jass and any code that isn’t Jass will be rejected.


I did participate in a spell contest and got wacked on the head with “memory leaks, you have memory leaks” and I got scolded by Vexorian with a “we want spells that are decently coded in this site, and while we approve GUI we still get to beat you on the head with it” (no he didn’t say that) and I still have the impression that GUI is alright and Jass is just a little better.

[Anitarf]

Originally Posted by The Dark One

Then we have a problem here.

No, you have a problem because you can only think about this in black and white. Just because something isn't accepted in our resource section doesn't mean it has to be banished from the site entirely. If you think GUI is good enough for you, keep using it; we won't ban you for it.

[The Dark One]

I do have the problem of thinking in black and white, but is that really a bad thing?
Is GUI good or bad (by the standards of good coding)?

GUI leaks (regardless of the memory leak tutorials), less efficient and no longer acceptable as a spell making tool. Why leave it there? Why not just get rid of it? Why not let the better alternative (Jass) take over?
What is “good enough for you” is supposed to mean? I am not going to work for 12 hours to make a map for myself. I make maps for others and if you don’t think GUI is good enough, and I think there are others who rightfully think that too, then I should learn Jass to please the people, right?

I apologize for being argumentative (part of my nature), but if something isn’t acceptable anymore then it is beneath the standards and should be disposed of, right?
I have been in a discussion like this one before, but every time we get to this point, good Jass using coders say: “you better learn Jass” but they never go ahead and say: “GUI is bad”. They say: “GUI isn’t … Jass is better, but if you like GU then it is ok” but GUI isn’t ok and you wouldn’t submit a GUI spell to contest even though you can.

What is preventing you from saying that GUI should be totally replaced with Jass (save for the casual use, like in cinematics and onetime events)?

[Bribe]

GUI is a part of WC3 whether we like it or not, and GUI is, in pretty much 100% of cases, where we all started out. It's not complete trash, just mostly trash.

JASS is not just a little better, it can do many, many things which GUI cannot do, and run them consistently with at least 2x better speed. And when you learn JASS, complex triggering becomes a breeze and you'll spot your memory leaks before your very eyes, instead of the "does this leak?" question which plagues many GUI-dependents.

vJass, on the other hand, is not even comparable to GUI. Without the limitations and grievances of World Editor and without the annoying table-tree which you must select from, with private members, inheritance, textmacros, modules, delegates and a plethora of other cool features, you're playing big-leagues.

[Anitarf]

Again, while we think vJass is considerably better than GUI, that does not automatically mean that we think everyone should learn vJass or GTFO. Standards that apply to the resource section needn't apply to the whole site, in fact, the whole point of the resource section is to have tougher standards. The site is designed to serve the community, that is why GUI isn't accepted in the resource section (because we think the community is best served by having only the best resources at its disposal) while it is still supported elsewhere (because many people use GUI and can not/do not want to learn vJass, but they are still a part of this community and so the site should serve them too).

[DioD]

GUI is fast and easy way to make something like framework for actual code.

One time events (like cinematics) is leak proof, few handles is not issue.