   Luabind: ownership and destruction!
  Hi everyone,I ve been pulling my air for awhile on this issue, I want a remove ownership destruction from Luabind, and manage my own garbage via C++;The doc says: Adopt: Used to transfer ownership across language boundaries.indexThe index which should transfer ownership, _N or resultHere is what I do:.cppclass_<Object>("Object").def(constructor<>(), adopt(result)).luamyObject = Object();luabind/src/object_rep.hppbut when lua_close() is called, it still want to delete its pointer:template<class T>struct delete_s{static void apply(void* ptr){delete static_cast<T*>(ptr); <<<<<< goes here!}};What did I missed?[Edited by - golgoth13 on February 25, 2009 5:04:26 PM]
  adopt(), and return value policies in general, doesn't work with constructors. Even if it did, adopt(result) in this case would actually mean "transfer ownership from C++ to Lua". A possible workaround would be add a function that releases the ownership:void release_ownership(Object*){}...class_<Object>("Object")  .def(luabind::constructor<>()),  def("release_ownership", &release_ownership, adopt(_1))and then wrap Object.__init() in Lua:local oldinit = Object.__initfunction Object.__init(self)    oldinit(self)    release_ownership(self)endI'm curious though; how does this work? Who manages the Object instances?   ;  Have you tried using smart pointers? (for example boost::shared_ptr or std::tr1::shared_ptr)class_<Object,shared_ptr<Object> >("Object")...As long as you hold a reference in c++ lua shouldn't be able to delete the object.   ;  Hi again, I ve posted on the Luabind mailing list, but my message is on old for some reason…Here is a simplify version of my work:.cpp  module(in_lua)  [   /// Base class for all classes.   class_<Object, boost::shared_ptr<Object>>("Object)   .def(constructor<>())   ,   class_<Actor, Object, boost::shared_ptr<Object>>("Actor)   .def(constructor<>())   .def("SetGeometry", &Actor::SetGeometry)   ,   class_<Cube, Object, boost::shared_ptr<Cube>>("Cube")   .def(constructor<Float, Float, Float>())  ];.luamyGeo = Cube(1,1,1);myActor = Actor();myActor:SetGeometry(myGeo);App onExit():1 - delete all C++ objects.3 - lua_close().I m using the boost::shared_ptr because it does not call the C++ object destructors when lua_close() is called. It all works fine, but my problem occurs when myActor:SetGeometry(myGeo); is present, lua_close() try to delete myGeo when it has already been deleted. And BAM!I ve also tried .def("SetGeometry", &Actor::SetGeometry, adopt(_2))In this case myGeo is not recognized on the C++ side… I m in the dark now… I ve tried a zillion possibilities so far…Complementary questions:Is it _<Cube, Object, boost::shared_ptr<Cube>>("Cube")Or_<Cube, Object, boost::shared_ptr<Object>>("Cube")?Do we need to put the space like so?_<Cube, Object, boost::shared_ptr<Object> >("Cube")I ll try the dw9 method... thx again![Edited by - golgoth13 on February 24, 2009 10:51:15 AM];  What do you mean by "1 - delete all C++ objects." ? Are you deleting objects wrapped by shared_ptr manually?   ;  yes, every objects is handle by a manager, knows who owns who and is in charge of deleting any orphans on cue or everything when the app exit. so I don’t need Lua to sneak in my garbage. In fact, if we could omit auto garbage collection, I would. I m stunt we have to macro manage this, quite a turn off so far.   ;  shared_ptr will delete the wrapped object automatically, if you have your own memory manager you may also need to write a wrapper class to be used in lua.EDIT: boost::intrusive_ptr may be useful.[Edited by - Kambiz on February 24, 2009 11:23:20 AM];  Your mixing 2 different memory management paradigms, managed and unmanaged memory models . Your going to have to accommodate one or the other, or not share any data between them at all. Even then, if Luabind is anything like Mluabind, it should allow you to use smart pointers in place of raw pointers to your objects in Lua, as Kambiz suggested, this should solve your memory sharing issues, since counted pointers don't deleted until all instances are destroyed, which you can make sure as long as you hold an instance in C++ Lua can't destroy your object, with the added benefit if you ever want Lua to manage the memory you can do that also.Good Luck!-ddn;  a wrapper? interesting... but to wrap what? going to all C++ classes and derived them in Lua? I don’t think so... Gaining speed is awesome but almost a bonus in my case… I m trying to removed any glue code and make scripting easier to maintain with Luabind.I thought Luabind was an interface to communicate directly with c++, no more, no less… In this case:myActor:SetGeometry(myGeo);why would Luabind keep a reference of an object passed as a parameter?  it doesn’t make any sense….why is it intervening in managing memory in the first place? I don’t mind inviting Luabind in my living room, but if I have to change the colors of my bedroom walls to make it happy,  I m going to get cranky!I m investigating intrusive_ptr… thx for your inputs gentlemen.Ddn3: Unfortunately MLuabind is not 64 bit friendly so I had to go back to Luabind.;  I should have mentioned that using a smart pointer that doesn't delete is a simple solution. Maybe something like this:struct object_ptr{    object_ptr(Object* p) : p(p)    {}};Object* get_pointer(object_ptr const& x){    return x.p;}object_ptr* get_const_holder(object_ptr*){    return 0;}...class_<Object, object_ptr>("Object")Of course, in:myActor:SetGeometry(myGeo);luabind doesn't create any references to the parameter. I don't know what made you think that. For obvious reasons it does keep a reference to instances created in Lua.   