lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Yes, I thought about that... the downside is that it would require a
little more effort on the Lua side (i.e when do you use the object
itself, vs lookup the ID), and I feel it is important to streamline the
Lua coding as much as possible, as it will be exposed to (advanced)
users, not just devs.  More streamlined == less documentation == less
support == happier devs :-)

And even so, I would still need to handle the situation where some
wayward Lua coder stores a reference (rather than its ID), which would
likely bring the whole game down if the script used it after the
underlying object were deleted.  I need to make sure that can't happen.

If you are interested, I explored some of the alternate strategies here:

Sean Riley wrote:
Another possible strategy is to store an ID rather than a pointer in the
userdata object. That way you can lookup the ID to see if the object
still exists, instead of dereferencing a pointer that may have been

-----Original Message-----
From: [mailto:lua-] On Behalf Of Watusimoto
Sent: Monday, July 06, 2009 10:06 AM
To: Lua list
Subject: Re: Lunar, C++, and premature object destruction


Thanks for your response.  I may have found a solution just last
You are right that with Luna, the C++ code is unaware of any
that Lua has to an object, so when C++ is done with it, it gets
creating the problem I reported.  My solution was to rearchitect my
Ship/LuaShip relationship, such that there is no longer a one-to-one
relationship.  When Lua wants a LuaShip, I create a new one, and let
control its lifespan.  I used a reference-counting pointer on LuaShip
refer back to the Ship, so that if the Ship is killed and deleted, the
LuaShip pointer to it is set to NULL, and I can detect and handle that
situation when dealing with the LuaShip object.  That let me remove
pointer from Ship to LuaShip that led to the problems in my previous

The only drawback to this solution is that I end up creating a lot of
LuaShip objects (the Lua script may ask for several such references
game cycle), whereas in my previous scheme, there was only one for
Ship.  But it does work -- Lua can hold or delete the LuaShip as it
likes, and C++ doesn't care; it will just create another when it needs

The only lingering problem I'm having is that while mucking around
this, I found that some objects aren't being fully destroyed, leading
a memory leak, but I think this is purely a C++ problem, and not
to any of the above.


Sean Riley wrote:
Looking briefly at the Lunar code, I don't see anything that tries
handle the case of the object being deleted from the C++ side.  The
cleanup appears to be when the object's associated userdata is
collected from the lua side.

Maybe you could always delete the ship from the lua code? This would
require a wrapper function that calls into lua to nil out the
to the shup in script, causing it to be garbage collected.

-----Original Message-----
From: [mailto:lua-] On Behalf Of Watusimoto
Sent: Thursday, July 02, 2009 1:04 AM
Subject: Lunar, C++, and premature object destruction

I'm working on a game that uses Lua to control robot players,

C++, and bound with Lunar, and am having problems controlling the
lifespan of objects created in C++ and referenced in Lua.  (It's at, if you are curious, and the linked wiki


examples of some robot scripts.)

My primary object is a Ship.  The lifetime of the Ship object is
completely controlled by C++.  I also have a proxy object, called
LuaShip, that contains a pointer to the Ship, and handles all the
requests for information about the Ship from the Lua script.  The
is that when the Ship is destroyed, the pointer on the LuaShip will
set to NULL, and any future requests to the LuaShip can be


handled (probably by generating an error of some sort).  The

exposed to Lua via Lunar if the robot script requests it (using a
getShip() method or somesuch).

The Ship object also contains a pointer to its LuaShip proxy.  My
problem is that when the Ship object is destroyed, C++ seems to
that all pointers to the LuaShip are gone, and it is OK to destroy
LuaShip as well.  It does not seem to recognize when a Lua instance
also referring to the LuaShip.  The result is that the LuaShip is
destroyed, and the Lua script is now left holding a reference to
nothing.  When the script acts on it (thinking it's still valid),
app crashes.

My questions are 1) Is this an appropriate architecture for

instances that can have persistent references to C++ objects (Ship
this case) that can be deleted without warning, and 2) are there
good examples of code that uses Lunar in this manner that I can


to see where my problem might be?

Thank you,