|
At 2003-04-26 00:22, you wrote:
class 'my_class1' function my_class1:__init() self._my_hardware_resource = create_hardware_resource() end class 'my_class2' function my_class2:__init() self._my_class1 = my_class1() end function my_class2:free_hardware_resources() self._my_class1 = nil -- note that the class above is still not -- released... must gc. collectgarbage() -- now 'my_class1' has been gc'ed, but -- the internal member '_my_hardware_resource' -- has not... must call gc again to do that. collectgarbage() end
The problem is really that the _my_hardware_resource will not be nil:ed until my_class1 is collected. Which means that the garbage collector first marks my_class1 and not _my_hardware_resource then collects my_class1. luabind's gc-event will then free the table in which _my_hardware_resource is stored.
One solution to this could be to have some kind of destructor's in luabind (doesn't exist yet) and invoke the garbage collector again when my_class1 is collected. Or (maybe the more efficient way) to have an explicit cleanup method which will nil all your members, and then invoke the gc. The latter will only have to invoke the gc once.
The lua-class instances are implemented as user-data in luabind, this is because they may need to access methods and properties from a derived C++ class. This case though, where the lua-calss doesn't derive from anything, could probably be optimized to use a lua-table only.
---Arvid Norberg