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

["Angelo Mottola" <a.mottola@xxxxxxxxxx>]

> Why? This sounds like over-optimization to me. Hopefully 
> nobody is going to access config variables very often? (At 
> least that seems to be the case for all variables in my 
> allegro.cfg.) If a config variable needs to be re-used, I 
> think the normal thing would be to save it in a program 
> variable anyway, right? It's going to take at least time 
> proportional to the length of the config variable name to 
> compute the hash key anyway, and converting a string to a 
> number takes time proportional to the length of the string 
> representation of the number, so the slowdown will probably 
> be something like a factor of 2. IMHO, having the same file 
> format that most other programs, and a clean easy to use 
> interface both for the person who hacks config files and to 
> the programmer is far more important than speed in this case.

I think it was clear that these new config routines were going to be
created to be used in a lot of different contexts. While I understand
that using these for key state access may is a performance loss,
consider the many other uses these can have.
Personally I'd go for a good balance between performance (speedwise) and
ease of use; the prototypes I'm presenting are meant to find the best
solution, so we can discuss the best path to follow before actually
adding the new code to the library.

I'll summarize our current problem here: we have the following decision
to take. We can:

1) Store variables in memory using their real type. An int is stored as
an int, etc.
Pro: fast access to the variable once it's already in memory, as no type
conversion is involved.
Con: the data type is apparently (if we don't find a way to solve it)
lost when saving the variables to disk.

2) Store variables in memory all as strings. This is the current way
Allegro does the job.
Pro: simplifies manual editing of the config files, as you don't have to
worry about what variable is what.
Con: small performance loss when accessing the variables in realtime,
due to the type conversion.

I'd go for approach 1, guessing variables types when loading them from a
config file... Some variables could change type during the process, but
the user won't notice it anyway.

BTW: over-optimization is good if you can! :)

--
Angelo Mottola
a.mottola@xxxxxxxxxx
http://www.ecplusplus.com