Hashtable recycling, well done?

[GetTriggerUnit-]

For my map, I'm using many hashtables so I though that making an hashtable recycling snippet would be nice. Now, I need to know if it's well done.

Comments?

library HashtableUtils initializer init

    globals
        private constant integer MAX_HASHTABLES_ALLOWED = 500
        private hashtable array hasht
        private boolean array used
    endglobals
    
    function NewHashtable takes nothing returns hashtable
        local integer i = 0
        loop
            set i = i + 1
            if used<i> == false then
                return hasht<i>
            endif
            exitwhen i &gt; MAX_HASHTABLES_ALLOWED
        endloop
    endfunction
    
    function ReleaseHashtable takes hashtable h returns nothing
        local integer i = 0
        call FlushChildHashtable(h)
        loop
            set i = i + 1
            if hasht<i> == h then
                set used<i> = false
                return
            endif
            exitwhen i &gt; MAX_HASHTABLES_ALLOWED
        endloop
    endfunction

    private function init takes nothing returns nothing
        local integer i = 0
        loop
            set i = i + 1
            set hasht<i> = InitHashtable()
            set used<i> = false
            exitwhen i &gt; MAX_HASHTABLES_ALLOWED
        endloop
    endfunction

endlibrary
</i></i></i></i></i></i>

 

[Jesus4Lyf]

It's terrible. Rip off Recycle.
If you have a loop, it is wrong.

 

[uberfoop]

First, I can't think of any use for this.

Second, you use an O(n) get and release algorithm. That's just bad.

Third, it won't even compile, because:
1-FlushChildHashtable flushes the children stored under a parent key and thus takes two inputs, the hashtable and the parent key you want flushed. Perhaps what you wanted was FlushParentHashtable.
2-Your NewHashtable function can make a compiler unhappy due to its if-statement return scheme. It needs a return on the outside.



So yeah:

It's terrible.

 

[Jesus4Lyf]

Oh yea, btw, hashtable recycling isn't possible with flushing implemented.
FlushParentHashtable seems to destroy a hashtable basically (well, it definitely makes it unusable).

So if you don't flush it yourself, it will leak. Hence why this isn't in Recycle - you can't make a recycling interface that promises a hashtable will be like a new hashtable created by [LJASS]InitHashtable[/LJASS].

 

[kingkingyyk3]

lol, I use 3 hashtables only in my map. It is too overkill.

 

[SerraAvenger]

easiest way to recycle anything, if you'ld ask me:

struct recycletable
  hashtable table
  static method create takes nothing returns nothing
      local thistype this = thistype.allocate()
      if table == null then
           set table = InitHashtable()
      endif
      call StoreInteger( table, -1, -1, this )
      return this
  endmethod
  method onDestroy takes nothing returns nothing
        call FlushParentHashtable(h)
  endmethod
endstruct

EDIT: Okay. Taking into consideration what J4L said about FlushParentHashtable, it is impossible to recycle hashtables anyway.

 

[Jesus4Lyf]

>struct recycletable
Ew! You'd need to keep track of the struct...

 

[SerraAvenger]

>struct recycletable
Ew! You'd need to keep track of the struct...

I thought it was obvious that these two are used:

Get() -> hashtable{ return recycletable.create().table; }
Recycle ( hashtable t ) { recycletable( LoadInteger( t, -1, -1 ) ).destroy; }

Of course, we can inline struct creation and code everything ourselves. But since it is already done by vJASS, and speed often doesn't matter that much anyway, we can just (ab)use the struct recycling mechanism.

 

[Nestharus]

Until someone comes along who doesn't thus making a better design than yours ><

At this point I've already made definitions and what not to do inlined struct allocation and deallocation, lol.

I also always use struct extends array as plain structs have quite a bit of extra code associated with them (triggers and what not)

 

[Jesus4Lyf]

Oh, I see. But it's unstable and slow...
Kinda clever.

Recycling shouldn't have structs at all. It should just be a stack of x.

 

[Xorifelse]

Dude, seriously you come up with the worst rip off systems, no offense.
Why recreate something that has been done before, and why not use struct interfaces to return new hashtables.

For example, if the hashtables where in a struct, i'd simply do..


[lJASS]set PrivateVarOfHashTable = yourSystem.create()[/lJASS] // returning a unique ID of the table, so it can't be overwritten by another system.

Also, polymorphism is a thing you should consider adding, instead of using those lame native names, try some inline methods like:

[lJASS]set yourSystemVar[handle] = value[/lJASS] Where the primary key is the struct ID, and where handle is transformed with GetHandleId() automatically.

However, systems like these have been done before and someone I know is about to release a gigantic system supporting everybody's needs. Including a highly sophisticated hashtable system.

 

[Jesus4Lyf]

You make no sense.

>why not use struct interfaces to return new hashtables.
You need to explain what you mean here.

>returning a unique ID of the table, so it can't be overwritten by another system.
Hashtables don't need IDs...

>Where the primary key is the struct ID
Primary key?

>where handle is transformed with GetHandleId() automatically.
Why would hashtable recycling use GetHandleId?

>However, systems like these have been done before
Actually, hashtable recycling has not, because you can't encforce recycling hashtables correctly (have the result be like a hashtable coming out of [LJASS]InitHashtable()[/LJASS]). They can't be cleared like GroupClear or PauseTimer.

>someone I know is about to release a gigantic system supporting everybody's needs. Including a highly sophisticated hashtable system.
Experience seems to suggest that mappers will be less eager than you are.

 

[GetTriggerUnit-]

kk it's shit.

Enough said. thread.close();

 

[kingkingyyk3]

kk it's shit.

Enough said. thread.close();

lol