RE: Parsing to byte code

["Josh Jensen" <joshj@...>]

> From: Roberto Ierusalimschy [mailto:rieru@delirius.cs.uiuc.edu] 
> On Mon, 10 Sep 2001, Josh Jensen wrote:
> 
> > [...]  The most
> > annoying thing about 4.1 Alpha was the change from 
> lua_pushuserdata() 
> > to lua_newuserdatabox().  I couldn't figure out why the Amped frame 
> > rates went to pot after integrating it.  It was because 
> > lua_newuserdatabox() allocates memory for the same pointer 
> EVERY time 
> > it is called, resulting in many, many new allocations per 
> frame.  The 
> > whole point was just to pass a C pointer to Lua so a 
> callback could be 
> > made to a C function with that pointer.  The 4.1 Alpha 
> behavior must 
> > have been different than 4.0's lua_pushuserdata(), because I am 
> > positive this didn't occur then.
> 
> I thought that was discussed in the list. Until Lua 3.2, 
> lua_pushuserdata coalesced equal pointers into a single 
> userdata. Although that was frequently the "correct" 
> behavior, sometimes it was not. Moreover, it could lead to 
> inconsistencies when you changed the tag of a userdata (this 
> flaw was pointed out by ET). So, we decided to simplify Lua, 
> and provide only the more primitive lua_newuserdatabox, that 
> always creates a new userdata when it is called. It is up to 
> the C code to avoid calling it everty time. (E.g. it can use 
> lua_pushvalue, if the pointer came from Lua; or it can use a 
> table to hash pointers to userdata.)

No, you're right, Roberto.  It was discussed on the list, and since
documentation isn't totally up to date for 4.1 Alpha, the repercussions
of lua_newuserdatabox as opposed to lua_pushuserdata wasn't immediately
obvious to me.  The only downside now to this approach is the code
pushing user data becomes more complex in EVERY part of the application,
if you don't want memory allocated every time.

Josh