AW: Functions prototypes and real #defines

["Michael Flad" <MichaelFlad@...>]

Did you profile it the way it is coded below, i.e. create a
table for each iteration? Most time you won't need that
flexibility and creating the table only once is enough?

Regards,

  Michael



> -----Ursprüngliche Nachricht-----
> Von: lua-bounces@bazar2.conectiva.com.br 
> [mailto:lua-bounces@bazar2.conectiva.com.br] Im Auftrag von 
> Quinn Tyler Jackson
> Gesendet: Sonntag, 9. Mai 2004 06:27
> An: Lua list
> Betreff: RE: Functions prototypes and real #defines
> 
> 
>  > By the way, is there some way of creating "real
> > > #defines" in Lua?
> >
> > You don't need to. Because Lua strings are pooled, the 
> equality test 
> > is just a pointer comparison, so the following is a perfectly 
> > efficient way to do
> > things:
> >
> >     if enemy.type == "ENEMY1" then ... end
> >
> > Or if there are lots of choices:
> >
> >     local switch = { ENEMY1 = function() ... end, ENEMY2 = ... }
> >     switch[enemy.type]()
> 
> The above use of tables with functions to emulate switches 
> caught my eye, so I tried it with a long if ... elseif ... 
> end chain (well, 8 choices ... not so long, and I used a 
> global rather than local table for the choices), and it 
> turned out to profile exactly the same speed as the if ... 
> elseif .. end chain. (The local table version was about 1 ms. 
> slower for my test.)
> 
> The unexpected side effect was that the profiler code I'd 
> written didn't seem to get called back on the switch[s]() 
> call, and so the timings/hit counts for the functions in the 
> table disappeared.
> 
> I shall never cease to be amazed by the versatility of Lua.
> 
> --
> Quinn
>