Strings and GC - was RE: Using full userdata as table index?

["Kevin Baca" <lualist@...>]

I had a similar issue where I wanted to index tables using an opaque
C-generated id object.

The id was encapsulated in a user data.

Each call to getId() generated a new user data, so it was not possible
to use it as an index.  The solution was to convert the id to a unique
string and use that as a key.

I discarded whole thing because of the number of strings that would be
generated and because of my (possibly wrong) understanding that lua
doesn't GC strings.

Was increased performance was the reason for making strings not
collectable?

I wonder if it would be better to make only literal strings not
collectable.  I think other languages (e.g. Java with string tables) do
something similar.

Would someone more knowledgeable than myself please clarify the
string/GC issue?

Thanks.

-Kevin

> -----Original Message-----
> From: lua-bounces@bazar2.conectiva.com.br 
> [mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of scott
> Sent: Tuesday, February 10, 2004 11:06 AM
> To: Lua list
> Subject: Re: Using full userdata as table index?
> 
> 
> 
> 
> Just because your userdata object has the same value, doesn't 
> mean that it is the same object.  AFAIK the table lookup 
> occurs by reference, not by value.  Therefore, two different 
> userdata objects could both be refering to the same guid, but 
> still be two refering to two different lua objects.  
> An example from my engine...
> 
> foo = GO.create( "obj_barrel_exploding" )
> print( tostring(foo) )
> 
>  --> go_ptr: obj_barrel_exploding (49.50, -8.12, 4.66)
> 
> bar = {}
> bar[foo] = "yippee"
> print (bar[foo])
> 
>  --> yippee
> 
> footoo = foo
> print(tostring(footoo))
> 
>  --> go_ptr: obj_barrel_exploding (49.50, -8.12, 4.66)
> 
> print( bar[footoo] )
> 
>  --> yippee
> 
> objs = Scene.getObjectsInRange( Actor.getPos("player"), 10 )
> 
>  -(omitted debug dump here to find index of new barrell)-
> 
> print( objs[2] )
> 
>  --> go_ptr: obj_barrel_exploding (49.50, -8.12, 4.66)
> 
> print( tostring(bar[objs[2]]) )
> 
>  --> nil
> 
> So, the first lookup worked because foo and footoo were 
> references to the same userdata.  But the second lookup 
> failed because, although objs[2] has the same value as 
> footoo, it isn't the same object.  Any chance you are seeing 
> something similar?
> 
> scott
> 
> -- 
> --------------------------------------------------------------
> ----------
> scott jacobs                                   
> scott+lua@escherichia.net
> --------------------------------------------------------------
> ----------
>