Hashtable as GUI leak protection?

[George Stinz]

Given an action like such:
Create 1 Footman for Player 1 (Red) at (Center of (Playable map area)) facing ...

(Center of (Playable map area)) will create a point which will not be garbage collected, as I understand it.

Therefore, most tutorials will recommend the following explicit action:

Set Temp_Point = (Center of (Playable map area))
Unit - Create 1 Footman for Player 1 (Red) at Temp_Point facing Default building facing ...
script: call RemoveLocation (udg_Temp_Point)

Question:
Would this be sufficient/preferred to the above leak protection?
Hashtable - Save (Center of (Playable map area)) as 1 of Key(This Trigger) in GameProperties
Unit - Create 1 Footman for Player 1 (Red) at (Load 1 of Key(This Trigger)) facing Default building facing ...

It's one less line of "code" but is it better?

Edit: in fact, does this actually avoid a leak?

 

[Rahko]

Leak happens when a point is referenced to, thus the point is "created", but then you lose the information it actually stores. I.e. If you imagine this point as actual object: you create this object at the center of the playable map area when you reference to that point upon creation of the unit. Then when you create another unit, it creates another new object at some location. But the first point object that is standing at the middle of map is still there, and you literally have no way to now have access to that information. It is lost, but still exists, thus taking up memory. That's why you have to destroy the point object when you still have access to it, but don't need it anymore.

You're system is just the same as saving the point to a variable: you would still have to clear the information from the hashtable (hashtables can actually leak quite a lot, if they aren't cleared correctly, because they can store large amounts of information). You can, however, use hashtables just as you could use temp variables, and I've even seen this in some maps. I just find temp variables a lot easier to handle.

 

[Pyrogasm]

Even clearing the hashtable wouldn't fix the leak in this case. You'd simply remove the reference to the point object but it still exists.

 

[George Stinz]

Thanks, it makes sense. A further question would be then, can you help to clarify:

Assigning a global variable to something, then clearing it, in a function (trigger), in the normal programming world would precisely be non-MUI. But here in WC land it's considered MUI. My question is:

Is it MUI because:
- With no waits, the trigger will run so fast it's highly unlikely to be run twice at the same time (but still possible)
- The trigger doesn't commit the value of the variable until end of function (each run will go as expected but will clobber values)
- Something else

Trying to understand why exactly it's OK to use globals to achieve this, so I can decide how to handle leaks on my map.

 

[Pyrogasm]

Wc3 is single-threaded. A trigger can interrupt another trigger if something the initial trigger does causes the secondary one to fire, but otherwise only one trigger can be 'running' at a time.

 

[Wrda]

On one hand, triggers are never run at same time, in fact, the same trigger can't be run at same time if for example 2 units are damaged by an AoE spell and the trigger detects when a unit gets damaged, it will run twice, sequencially from the first created unit to last. On the other hand, the same trigger can be "run" again while it is being executed.

 

[George Stinz]

OK, so the fact that it's global actually makes no difference then, as the game will only move on to the next in queue if there's a wait (I'm deducing).
Then that at least simplifies things dramatically. Thanks.

 

[Pyrogasm]

the game will only move on to the next in queue if there's a wait (I'm deducing)

Correct.