RE: 'revoking' a userdata

["Jasmin Patry" <jpatry@...>]

Another option is to have the userdata store a handle to the object,
instead of a direct pointer to the object.  You can then catch accesses
to deleted objects and treat them as (recoverable) run-time errors,
instead of hard crashes.  Depending on your application, in the release
version of the program you can remove this error-checking code.

One common type of handle scheme involves assigning a unique integer ID
to every object that is exposed to script.  You then maintain a map from
the ID to the object pointer.  Depending on the application, this can be
implemented very efficiently.

-jaz

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of Ben
Sunshine-Hill
Sent: Friday, September 02, 2005 3:57 PM
To: Lua list
Subject: Re: 'revoking' a userdata

On 9/2/05, DC <dcharno@comcast.net> wrote:
> Is it possible for the c/c++ side to 'revoke' a userdata from a
script?
>  For example, an object which exists in one level of a game, but is no
> longer used or valid in the next level?  If the script forgets to
> release the object it could persist.

Not really. What would happen to remaining references to the userdata?
If you just deleted the userdata, then accessing them would point into
unallocated memory. If you somehow magically nil'ed them, then they'd
be nil... and do you really want to check a userdata for being nil
every time you access it?

The solution here is to not forget to release the object. In any
garbage-collected language, the question of what is reachable and what
is not is paramount. If your userdata is not GCed, it means you have
told Lua, via a reference, that you don't want it to be GCed; that, of
course, is the bug.

Ben

> 
> One solution has been to destroy the lua state when transitioning
> between levels.  But, I want to be able to pass and maintain state.
>