RE: [AD] Allegro 5 new config routines, alpha 1

["Vincent Penquerc'h" <Vincent.Penquerch@xxxxxxxxxx>]

Title: RE: [AD] Allegro 5 new config routines, alpha 1

Random comments:

- how about having way smaller tables, and increasing their size
  as their density goes above a given parameter (so the user can
  set it to trade space/speed). This would require rebuilding the
  whole table probably, as well as recomputing hashes, but that
  would not be too bad I think.

- did you do tests to find out how many collisions there are for
  strings that all begin with the same prefix (eg "keyboard/")
  with your particular hash function ? MD5 comes to mind.

- i would add a boolean to your al_get_<type> functions, which
  would allow or not type conversion. And a return value (found
  or not) with the actual value returned in a pointer given as
  an argument to the function.

- i think al_get_hex is wrong (uses atoi when encounters a string,
  should use (u)strtol, which allows to specify the input base).

- i would add a pointer type (would obviously not be read/written
  from/to disk, but done at run time by the user). Also, maybe
  several of these, as in:
    typedef int user_type;
    user_type al_create_hash_type();
    void al_set_usertype(user_type type,const char *name,void *data);
    user_type *al_get_usertype(user_type type, const char *name);
  one user type only might be sufficient. just thinking there.

- i'm still not too comfortable with having to go through a number
  of hash lookups just to find out whether a key is down or not,
  but that's another story entirely :)

- Lua as a good implementation of hash tables, you might want to
  have a look at it to see how they solved the various problems
  dealing with hash table size, speeding up hashing of very long
  strings, etc, if you haven't already (www.tecgraf.puc-rio.br/lua/)

--
Vincent Penquerc'h