[Hashtable] Does using integer with array overwrites ?

[Ardenian]

Does using an integer with an array overwrites a slot ?

Example:

• Hashtable - Save Handle Of Point[1] as Hash_Location of HashInteger[1] in Hashtable

• Hashtable - Save Handle Of Point[2] as Hash_Location of HashInteger[2] in Hashtable

If HashInteger[1] and HashInteger[2] are both = 1, do they overwrite ?

 

[Flux]

Yes.

 

[Ardenian]

Damn, this makes everything a lot more complicated...

Thanks again!

 

[Bribe]

Instead of HashInteger 1 and 2, just use the integers 1 and 2.

 

[Ardenian]

Instead of HashInteger 1 and 2, just use the integers 1 and 2.

You refer to the name ?

I can just use a HashInteger then, I don't even need arrays or two different, if two different integer variables with the same value slot overwrite each other.

Just wondering, why did a moderator moved this to Triggers and Scripts ? Do questions like this do not belong to the WEHZ ?

 

[Bribe]

I moved 8 threads at once; to be honest, either forum suits this thread

 

[Dr Super Good]

I can just use a HashInteger then, I don't even need arrays or two different, if two different integer variables with the same value slot overwrite each other.

You are passing a value, not a reference. Hence it does not matter where the value comes from (HashInteger[1], HashInteger[2], udg_Banana, GetHandleId(unit), 1337, etc) since the function will only be passed the evaluated value. If this value is the same then the function will act as if it was given the same value.

If both the arguments of HashInteger[1] and HashInteger[2] evaluate to the same value of integer 1 then the function will be called twice with that parameter as integer value 1 and both calls will act accordingly. In this case it corresponds to the same key so will manipulate the same data within the hashtable which is not intended (key collision, second call will discard data from first).

What you could do is assign HashInteger[1] and HashInteger[2] different unique values. These could be generated from a sequence generator of sorts. Then both will be unique keys (have unique values) so no key collision will occur. Recycling numbers in a sequence generator is likely unnecessary as with over 32 billion unique numbers to choose from the chance of running out of unique numbers under normal use circumstances (2 hour WC3 session, possibly using a few dozen a second at most) is impossible. It is important that any unique key be properly cleared otherwise data could leak inside the hashtable and so degrade the hashtable performance.