Hashtables and Memory Leaks

[HydraRancher]

Definitely NOT (It ruins my trigger as well, seems that location isn't exist). Anyway I have changed save location to save real(LocX and LocY) instead and it works efficiently. (I don't really care much about leak but this force me to use real )



This may explain the reason why.

Believe me, use GetLocationX and GetLocationY is better.

This may explain the reason why you're doing it wrong?

I can't believe you that using LocX and LocY is better without anything more than you saying so.

 

[KaerfNomekop]

So TempPoint won't exist anymore if RemoveLocation is used, even if it's already saved in the hashtable?
I thought of just doing something like

call RemoveLocation(LoadLocationHandleBJ(GetHandleIdBJ(GetTriggerUnit()), udg_LocationInteger, udg_Hashtable)

Would that work?

 

[HydraRancher]

Are you trying to clear a hashtable? Just use the clear functions.

 

[Romek]

> When ever I've saved points into hashtables I save them directly. Like saving (Position of (Triggering Unit)). But does that create leaks?
It's not quite a leak, as you can still reference the location and remove it afterwards. When you no longer need that location, load it from the hashtable and use RemoveLocation. Leaks are handles that are still in memory that you're not using and have lost reference to.

> I believe that's what Romek means.
Yup.

> Believe me, use GetLocationX and GetLocationY is better.
I don't believe you.

> So TempPoint won't exist anymore if RemoveLocation is used, even if it's already saved in the hashtable?
TempPoint can point to any single location. If you store that location into a hashtable, you could reference it either by loading it from the hashtable, or using TempPoint (it would be the same location, regardless). You could set TempPoint to some other location if you wanted, and still be able to reference that first location through the hashtable (though TempPoint will now be a different location). Neither of these locations would be leaks until they were no longer being used. Using RemoveLocation(udg_TempPoint) removes whatever location TempPoint is set to. However, note that handles are pointers, so that'd also make all other references to that location null (such as ones that have been saved into hashtables), so you wouldn't be able to load that same location from a hashtable after. Basically, only remove locations once you're done with them. The actual location, that is. Not necessarily the variable.

> Would that work?
Well, yes. Why would you ever want to do that though?

 

[KaerfNomekop]

> When ever I've saved points into hashtables I save them directly. Like saving (Position of (Triggering Unit)). But does that create leaks?
It's not quite a leak, as you can still reference the location and remove it afterwards. When you no longer need that location, load it from the hashtable and use RemoveLocation. Leaks are handles that are still in memory that you're not using and have lost reference to.

> So TempPoint won't exist anymore if RemoveLocation is used, even if it's already saved in the hashtable?
TempPoint can point to any single location. If you store that location into a hashtable, you could reference it either by loading it from the hashtable, or using TempPoint (it would be the same location, regardless). You could set TempPoint to some other location if you wanted, and still be able to reference that first location through the hashtable (though TempPoint will now be a different location). Neither of these locations would be leaks until they were no longer being used. Using RemoveLocation(udg_TempPoint) removes whatever location TempPoint is set to. However, note that handles are pointers, so that'd also make all other references to that location null (such as ones that have been saved into hashtables), so you wouldn't be able to load that same location from a hashtable after. Basically, only remove locations once you're done with them. The actual location, that is. Not necessarily the variable.

Doesn't that do this?

 

[HydraRancher]

I believe he meant load it from the hashtable like Set TempPoint = Load 0 from Key(Triggering Unit) in Hashtable.

 

[KaerfNomekop]

So I do that, then clear TempPoint instead?

 

[HydraRancher]

Correct.

 

[NeuroToxin]

Sorry for the offtopic post, just reading this and had to quote Romek

> Believe me, use GetLocationX and GetLocationY is better.
I don't believe you.

 

[Bankde]

Sorry for the offtopic post, just reading this and had to quote Romek
> Believe me, use GetLocationX and GetLocationY is better.
I don't believe you.

LoL thank though. Anyway may I have your reason (Romek Reason)?
I have my own reason that real will not leak.

I believe Romek have better and there maybe sth I should learn.

 

[HydraRancher]

Yes, we know reals don't leak. So you're saying, we should instead of using a point, which would save ONE value, we should use TWO reals? When points work just as well.

 

[Romek]

> Yes, we know reals don't leak. So you're saying, we should instead of using a point, which would save ONE value, we should use TWO reals? When points work just as well.
It's not really about using one value instead of two.

In JASS, using two reals is always preferred over a location (with a minor exception of checking terrain height). Locations in general are pretty much GUI-exclusive, because of how inferior they are compared to using coordinates directly. Coordinates can be easily manipulated mathematically (whereas locations can't), and using them gives you the flexibility of easily doing whatever you want with positions. Almost all location functions (such as polar offset) first convert to reals, then do whatever they need to do, before converting the resulting reals back into a location. Then there's also the leak to clean up. Reals are, in theory, much more efficient and flexible than locations.

However. This is GUI, not JASS. There's a lot of support for locations compared to coordinates, which makes using reals quite difficult, and will probably result in converting them to a location quite often (or result in using relatively complicated custom scripts - though if you can do that, you shouldn't even be using GUI). There can also be quite a lot of maths involved with reals, and I'm sure you all know that anything past simple arithmetic maths is a pain to do in GUI.
Besides all of that, GUI is horrible efficiency-wise anyway, and there's nothing at all you can do about that. It's pointless to go out of your way to make a small efficiency tweak when every if-condition block (amongst many other actions) you use set that back in the opposite direction again. It's not a game-breaking difference, but it's more than enough to warrant prioritizing readability and usability over efficiency. Just stick to what GUI is best at: simple, English, readable* code.

Edit: You specifically mentioned using GetLocationX and Y. You're not accomplishing anything there, as you're using both locations and reals.

 

[NeuroToxin]

I love how you reply Romek, Your replies are always the best.

@This topic. All Romek was saying without reading his wall of text like I just did, is that GUI was made for Locations, (Not GUI, but it was made to USE locations) and JASS was used to make reals, so that way you can basically use natives, (no known source, just what I think) to efficientize it. (I'm using my word again)

 

[Bankde]

> Yes, we know reals don't leak. So you're saying, we should instead of using a point, which would save ONE value, we should use TWO reals? When points work just as well.
It's not really about using one value instead of two.

In JASS, using two reals is always preferred over a location (with a minor exception of checking terrain height). Locations in general are pretty much GUI-exclusive, because of how inferior they are compared to using coordinates directly. Coordinates can be easily manipulated mathematically (whereas locations can't), and using them gives you the flexibility of easily doing whatever you want with positions. Almost all location functions (such as polar offset) first convert to reals, then do whatever they need to do, before converting the resulting reals back into a location. Then there's also the leak to clean up. Reals are, in theory, much more efficient and flexible than locations.

However. This is GUI, not JASS. There's a lot of support for locations compared to coordinates, which makes using reals quite difficult, and will probably result in converting them to a location quite often (or result in using relatively complicated custom scripts - though if you can do that, you shouldn't even be using GUI). There can also be quite a lot of maths involved with reals, and I'm sure you all know that anything past simple arithmetic maths is a pain to do in GUI.
Besides all of that, GUI is horrible efficiency-wise anyway, and there's nothing at all you can do about that. It's pointless to go out of your way to make a small efficiency tweak when every if-condition block (amongst many other actions) you use set that back in the opposite direction again. It's not a game-breaking difference, but it's more than enough to warrant prioritizing readability and usability over efficiency. Just stick to what GUI is best at: simple, English, readable* code.

Edit: You specifically mentioned using GetLocationX and Y. You're not accomplishing anything there, as you're using both locations and reals.

That's the main reason. I agree that using GUI is not suitable with real. Location is really better here.

Thank Romek, again. >_<