Generating key integers for hashtables?

06-11-2009, 11:39 PM

Something like:

JASS:


globals
    key      KILLER
    private key SUMMONER
    private key STUFFSYS
endglobals

//...

call SaveHashTable( hs, STUFFSYS, KILLER , u)

->
[jass]

JASS:


globals
    constant integer      KILLER = 3
    private  constant integer     key SUMMONER = 4
    private constant integer     key STUFFSYS = 5
endglobals

//...

call SaveHashTable( hs, STUFFSYS, KILLER , u)

just an idea...

06-12-2009, 02:35 AM	#2
grim001	If you do that, Table shouldn't need to take a string for the parent key anymore.

06-12-2009, 02:56 AM	#3
Vexorian	Do it and break Table's backwards compatibility for 2D operator?

06-12-2009, 03:10 AM	#4
grim001	everyone is being forced to update stuff at the moment, anyway. If Table is going to be our general purpose wrapper for hashtable usage it shouldn't be slower than using it directly.

06-12-2009, 05:41 AM	#5
cohadar	This key stuff might prove more important that in seems. If you generate keys in a stupid way it might lead to collision and slow the hashtables down.

06-12-2009, 07:41 AM

Anitarf

Depending on their speed, hashtables might get used a lot, so this is a good way to avoid conflicts; however, if you use Table this shouldn't really be an issue (since Table.create() already gives you a unique missionkey), except if you want to use the 2D part of it but in that case you usually need it for dynamic keys, not constants, so you might as well make your own private hashtable for that particular system.

06-12-2009, 11:34 AM

grim001

Quote:

Originally Posted by Anitarf

if you want to use the 2D part of it but in that case you usually need it for dynamic keys, not constants

It is not really dynamic keys, it is more like several keys that are prefixed with the library's name, which can be replaced by declaring multiple keys within the library.

Quote:

Originally Posted by Anitarf

so you might as well make your own private hashtable for that particular system.

This works, but then you couldn't use Table's syntax.

Once we can benchmark hashtables (MindWorX said he's working on new stopwatch natives) we'll see whether a bunch of smaller hashtables has better performance than one large hashtable. If that's the case, Table.create() might as well return a brand new hashtable every time. If each library uses its own hashtable there would be no key conflicts, in which case this feature will be a little silly unnecessary. But I would still want it since it's nicer looking than manually declaring a bunch of integers.

06-12-2009, 12:41 PM

akolyt0r

gay solution:

JASS:

 globals
        private constant integer MAX_INSTANCES=8100 //400000
        //Feel free to change max instances if necessary, it will only affect allocation
        //speed which shouldn't matter that much.

    //=========================================================
        private hashtable HT
    endglobals

    private struct GTable[MAX_INSTANCES]

                private hashtable ht
                
                static method create takes nothing returns GTable
                    local GTable this = GTable.allocate()
                    set this.ht = HT
                    return this
                endmethod
                
                static method createPrivate takes nothing returns GTable
                    local GTable this = GTable.allocate()
                    set this.ht = InitHashtable()
                    return this
                endmethod                
                
        method reset takes nothing returns nothing   
                  call FlushChildHashtable(ht, integer(this) )
        endmethod

        private method onDestroy takes nothing returns nothing
            call this.reset()
        endmethod

        //=============================================================
        // initialize it all.
        //
        private static method onInit takes nothing returns nothing
            set HT = InitHashtable()
        endmethod

    endstruct

    //Hey: Don't instanciate other people's textmacros that you are not supposed to, thanks.
    //! textmacro Table__make takes name, type, key
    struct $name$ extends GTable

        method operator [] takes $type$ key returns integer
            return LoadInteger(ht, integer(this), $key$)
        endmethod

        method operator []= takes $type$ key, integer value returns nothing
            call SaveInteger(ht,  integer(this)  ,$key$, value)
        endmethod

        method flush takes $type$ key returns nothing
            call RemoveSavedInteger(ht, integer(this), $key$)
        endmethod

        method exists takes $type$ key returns boolean
            return HaveSavedInteger( ht,  integer(this)  ,$key$)
        endmethod

        static method flush2D takes string firstkey returns nothing
            call $name$(- StringHash(firstkey)).reset()
        endmethod

        static method operator [] takes string firstkey returns $name$
            return $name$(- StringHash(firstkey) )
        endmethod

    endstruct

createPrivate would be collisionsafe obviously ...
this solution isnt any good anyways, just to show the possibility..

EDIT: Fixed my constructors, damn i havent coded any JASS, for a long time now 0,o

06-12-2009, 12:58 PM

Vexorian

Quote:

It is not really dynamic keys, it is more like several keys that are prefixed with the library's name, which can be replaced by declaring multiple keys within the library.

One question though, I always thought you wanted access to mission keys so you had flexible ones. Yet you know say these static keys are acceptable, what's the difference between:

JASS:

globals
    key MEH

endglobals

function x takes nothing returns nothing
    set Table[MEH][4] = 5
endfunction

and:

JASS:

globals
    Table MEH

endglobals

function x takes nothing returns nothing
    set MEH[4] = 5
endfunction

function ini takes nothing returns nothing
    set MEH = Table.create()
endfunction

06-12-2009, 02:23 PM

#10

grim001

OK, I forgot, I do need dynamic missionkeys for something like this:

JASS:

set Table["GAbility_type_"+I2S(.getType())][GetHandleId(unit)] = ...
set Table["GAbility_category_"+I2S(.category)][GetHandleId(unit)] = ...

//otherwise it would be something like this:

globals
    StringTable TypeTable
    StringTable CategoryTable
endglobals

set TypeTable[I2S(.getType())+"_"+I2S(GetHandleId(unit))] = ...
set CategoryTable[I2S(.category)+"_"+I2S(GetHandleId(unit))] = ...

Technically, there is no way you can "need" a dynamic missionkey because you can always combine strings to produce anything you need for the key. But it is more annoying and produces more unique strings to do it that way.