I've attached a patch to weak_ref which fixes the issue I previously mentioned. The fix turned out to be fairly straight forward: I added an additional table to store the impl part of the weak_ref. This table is used with lua_ref so that the "id" will be unique to the weak_ref regardless of whether or not the value in the weak table has been removed or collected.
This prevents the same id from being used by two weak_refs at the same time, which previously could result in the Lua portion of a wrap_base derived class from being lost or aliased by another object.
-- Technical Director Unknown Worlds Entertainment http://www.unknownworlds.com ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ luabind-user mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/luabind-user |
Hi there, I know this is an old thread... Was there no follow-up on this? I've run into the same problem with weak references getting garbage collected when deriving from C++ classes.
Max's patch hasn't been integrated into luabind, as far as I can tell. I'm happy to fork my own luabind and patch it, but wondering why this was not put into the main repo -- was it not judged a correct fix? Thanks, Glen. |
It turns out that the patch does not fix my problem. After more web-searching, I see I should be using the adopt policy (http://www.rasterbar.com/products/luabind/docs.html#adopt), to pass Lua object ownership to C++. However, whenever I try to include luabind/adopt_policy.hpp, I get tons of errors (on Xcode 4.6.3 with clang or gcc).
With Clang LLVM: .../addons/ofxLua/src/luabind/luabind/handle.hpp:136:5: Expected member name or ';' after declaration specifiers .../addons/ofxLua/src/luabind/luabind/detail/has_get_pointer.hpp:82:3: Declaration does not declare anything .../addons/ofxLua/src/luabind/luabind/detail/has_get_pointer.hpp:83:3: Declaration does not declare anything .../addons/ofxLua/src/luabind/luabind/detail/has_get_pointer.hpp:91:71: Expected unqualified-id .../addons/ofxLua/src/luabind/luabind/detail/policy.hpp:534:45: Too many arguments provided to function-like macro invocation .../addons/ofxLua/src/luabind/luabind/nil.hpp:36:40: Expected unqualified-id .../addons/ofxLua/src/luabind/luabind/object.hpp:109:5: Declaration does not declare anything .../addons/ofxLua/src/luabind/luabind/object.hpp:110:5: Declaration does not declare anything .../addons/ofxLua/src/luabind/luabind/object.hpp:116:57: Expected unqualified-id .../addons/ofxLua/src/luabind/luabind/object.hpp:884:5: Expected member name or ';' after declaration specifiers .../addons/ofxLua/src/luabind/luabind/object.hpp:905:5: Expected member name or ';' after declaration specifiers .../addons/ofxLua/src/luabind/luabind/object.hpp:1249:37: Too many arguments provided to function-like macro invocation .../addons/ofxLua/src/luabind/luabind/object.hpp:1249:17: Function definition does not declare parameters .../addons/ofxLua/src/luabind/luabind/object.hpp:1251:53: Too many arguments provided to function-like macro invocation .../addons/ofxLua/src/ofxLua.h:590:20: No member named 'nil' in namespace 'luabind' .../addons/ofxLua/src/luabind/luabind/detail/has_get_pointer.hpp:94:33: Non-type template argument of type 'bool' is not an integral constant expression .../addons/ofxLua/src/luabind/luabind/detail/policy.hpp:195:9: No matching function for call to 'make_pointee_instance' .../addons/ofxLua/src/luabind/luabind/detail/has_get_pointer.hpp:94:33: Non-type template argument of type 'bool' is not an integral constant expression .../addons/ofxLua/src/luabind/luabind/detail/policy.hpp:195:9: No matching function for call to 'make_pointee_instance' .../addons/ofxLua/src/luabind/luabind/detail/policy.hpp:534:36: No member named 'check' in 'luabind::value_wrapper_traits<luabind::adl::argument>' With LLVM GCC: .../addons/ofxLua/src/luabind/luabind/detail/policy.hpp:534: Macro "check" passed 2 arguments, but takes just 1 .../addons/ofxLua/src/luabind/luabind/object.hpp:1249: Macro "check" passed 2 arguments, but takes just 1 .../addons/ofxLua/src/luabind/luabind/object.hpp:1251: Macro "check" passed 2 arguments, but takes just 1 .../addons/ofxLua/src/luabind/luabind/handle.hpp:136: Expected unqualified-id before '{' token .../addons/ofxLua/src/luabind/luabind/detail/has_get_pointer.hpp:82: Expected unqualified-id before ';' token .../addons/ofxLua/src/luabind/luabind/detail/has_get_pointer.hpp:83: Declaration does not declare anything .../addons/ofxLua/src/luabind/luabind/detail/has_get_pointer.hpp:90: Expected unqualified-id before ')' token .../addons/ofxLua/src/luabind/luabind/detail/has_get_pointer.hpp:94: 'luabind::detail::has_get_pointer_::impl<T>::value' is not a valid template argument for type 'bool' because it is a non-constant expression .../addons/ofxLua/src/luabind/luabind/nil.hpp:36: Expected unqualified-id before '__null' .../addons/ofxLua/src/luabind/luabind/object.hpp:109: Expected unqualified-id before ';' token .../addons/ofxLua/src/luabind/luabind/object.hpp:110: Declaration does not declare anything .../addons/ofxLua/src/luabind/luabind/object.hpp:115: Expected unqualified-id before ')' token .../addons/ofxLua/src/luabind/luabind/object.hpp:119: 'luabind::adl::is_object_interface_aux::impl<T>::value' is not a valid template argument for type 'bool' because it is a non-constant expression (and many more) As you can see, I'm using a version of luabind in the ofxLua project, but I also tried taking a copy of luabind directly from Git (https://github.com/luabind/luabind), but had a similar pile of compile errors. Anyone else run into something similar? More important, can anyone help me with this? Thanks, Glen. On Jul 22, 2013, at 2:02 PM, Glen F <[hidden email]> wrote: Hi there, I know this is an old thread... Was there no follow-up on this? ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ luabind-user mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/luabind-user |
How embarrassing, sorry for the noise, I was barking up the wrong tree. This turned out to be (of course) a stupid change where I was including adopt_policy.hpp before luabind.hpp -- doh!
Sorry. Now, when I try to use the adopt policy, I get errors like Sympaval had (in this thread: http://lua.2524044.n2.nabble.com/Remove-an-object-from-the-lua-state-tp7583423p7583425.html). He didn't manage to get adopt working when binding, but rather chose to instead use it with using call_function. Same as him -- I get errors like this, when trying to use adopt(_2) in a def(): .../boost/include/boost/preprocessor/iteration/detail/local.hpp:37:9: No member named 'consumed_args' in 'luabind::detail::adopt_policy<2, void>::only_accepts_nonconst_pointers' .../boost/include/boost/preprocessor/iteration/detail/local.hpp:37:9: No member named 'converter_postcall' in 'luabind::detail::adopt_policy<2, void>::only_accepts_nonconst_pointers' .../addons/ofxLua/src/luabind/luabind/detail/call.hpp:295:48: No member named 'apply' in 'luabind::detail::adopt_policy<2, void>::only_accepts_nonconst_pointers' And when I try to use it with call_function: .../addons/ofxLua/src/luabind/luabind/detail/call_function.hpp:200:20: No member named 'match' in 'luabind::detail::adopt_policy<0, void>::only_accepts_nonconst_pointers' Is this because the latest luabind requires C++0x/C++11 compilation and standard libs? Currently, I can't do that because I'm using it inside OpenFrameworks v0074, which still uses std::tr1 things -- but I guess I can try to change that locally (if that's the solution). Or should I go back to an older version of luabind? Thanks again (though I feel like I'm talking to myself ;-), Glen. On Jul 22, 2013, at 4:49 PM, Glen Fraser <[hidden email]> wrote:
------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ luabind-user mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/luabind-user |
On Tuesday 23 July 2013, at 10:11:13, Glen Fraser <[hidden email]> wrote:
> How embarrassing, sorry for the noise, I was barking up the wrong tree. > This turned out to be (of course) a stupid change where I was including > adopt_policy.hpp before luabind.hpp -- doh! > > Sorry. > > Now, when I try to use the adopt policy, I get errors like Sympaval had (in > this thread: > http://lua.2524044.n2.nabble.com/Remove-an-object-from-the-lua-state-tp7583 > 423p7583425.html). He didn't manage to get adopt working when binding, but > rather chose to instead use it with using call_function. > > Same as him -- I get errors like this, when trying to use adopt(_2) in a > def(): > > .../boost/include/boost/preprocessor/iteration/detail/local.hpp:37:9: No > member named 'consumed_args' in 'luabind::detail::adopt_policy<2, > void>::only_accepts_nonconst_pointers' > .../boost/include/boost/preprocessor/iteration/detail/local.hpp:37:9: No > member named 'converter_postcall' in 'luabind::detail::adopt_policy<2, > void>::only_accepts_nonconst_pointers' > .../addons/ofxLua/src/luabind/luabind/detail/call.hpp:295:48: No member > named 'apply' in 'luabind::detail::adopt_policy<2, > void>::only_accepts_nonconst_pointers' > > And when I try to use it with call_function: > > .../addons/ofxLua/src/luabind/luabind/detail/call_function.hpp:200:20: No > member named 'match' in 'luabind::detail::adopt_policy<0, > void>::only_accepts_nonconst_pointers' > The struct name "only_accepts_nonconst_pointers" is meant as an error message: adopt only works with non-const pointers (meaning that the adopted type must be both a pointer and a non-const one). Hope I could help, Christian > Is this because the latest luabind requires C++0x/C++11 compilation and > standard libs? Currently, I can't do that because I'm using it inside > OpenFrameworks v0074, which still uses std::tr1 things -- but I guess I can > try to change that locally (if that's the solution). Or should I go back > to an older version of luabind? > > Thanks again (though I feel like I'm talking to myself ;-), > Glen. ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ luabind-user mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/luabind-user |
The struct name "only_accepts_nonconst_pointers" is meant as an error message: I declare my class binding like this: class_<Actor, Actor_wrapper, boost::shared_ptr<Actor> >("Actor") .def(constructor<const string &>()) .def("draw", &Actor::draw, &Actor_wrapper::default_draw) ]; And the function I'm trying to call from C++ is like this: boost::shared_ptr<Actor> fromLua = luabind::call_function<boost::shared_ptr<Actor> >(mLua, "makeActorSubclass", "bobby")[luabind::adopt(luabind::result)]; The function makeActorSubclass is a simple Lua script that creates an instance of a class derived from Actor in Lua (this creation code works fine without the adopt policy stuff...except it doesn't transfer ownership to C++, so the object gets garbage-collected later on!). function makeActorSubclass(name) return ActorSubclass(name) end Any ideas on how to get rid of my const problem? I do see the following comment in the luabind docs: get_const_holder() has been removed. Automatic conversions between smart_ptr<X>and smart_ptr<X const> no longer work. But I'm not sure what that means, and whether it applies in my case (I don't have any smart_ptr<X const> usages that I know of). Glen. On Jul 23, 2013, at 10:55 AM, Christian <[hidden email]> wrote: On Tuesday 23 July 2013, at 10:11:13, Glen Fraser <[hidden email]> wrote:Now, when I try to use the adopt policy, I get errors like Sympaval had (in ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ luabind-user mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/luabind-user |
On Tuesday 23 July 2013, at 12:00:29, Glen Fraser <[hidden email]> wrote:
> > The struct name "only_accepts_nonconst_pointers" is meant as an error > > message: adopt only works with non-const pointers (meaning that the > > adopted type must be both a pointer and a non-const one). > > Thanks, Christian -- I saw that, but I don't know how to fix it. Presumably > this is related to the fact that the object I'm trying to "adopt" is held > in a smart pointer (boost::shared_ptr). But I haven't declared the > smart_ptr as const anywhere… > Adopt checks exactly for const plain pointers and will issue said error message otherwise. And if you think about it, it makes sense: Plain pointers do not have any particular ownership semantics, so you must tell luabind about it using policies such as adopt. Smart pointers on the other hand, do already have ownership semantics: shared_ptr e.g. has shared ownership. > I declare my class binding like this: > > class_<Actor, Actor_wrapper, boost::shared_ptr<Actor> >("Actor") > .def(constructor<const string &>()) > .def("draw", &Actor::draw, &Actor_wrapper::default_draw) > ]; > > And the function I'm trying to call from C++ is like this: > > boost::shared_ptr<Actor> fromLua = > luabind::call_function<boost::shared_ptr<Actor> >(mLua, > "makeActorSubclass", "bobby")[luabind::adopt(luabind::result)]; > > The function makeActorSubclass is a simple Lua script that creates an > instance of a class derived from Actor in Lua (this creation code works > fine without the adopt policy stuff...except it doesn't transfer ownership > to C++, so the object gets garbage-collected later on!). > > function makeActorSubclass(name) > return ActorSubclass(name) > end > So the lua part of your object get's collected? I think I had a similar problem, which I solved using a hack in my wrapper class, by doing the (here) crucial part of adopt manually using a member function like this: > Any ideas on how to get rid of my const problem? I do see the following > comment in the luabind docs: > > get_const_holder() has been removed. Automatic conversions between > smart_ptr<X>and smart_ptr<X const> no longer work. > > But I'm not sure what that means, and whether it applies in my case (I don't > have any smart_ptr<X const> usages that I know of). > > Glen. > > On Jul 23, 2013, at 10:55 AM, Christian <[hidden email]> wrote: > > On Tuesday 23 July 2013, at 10:11:13, Glen Fraser <[hidden email]> > >> Now, when I try to use the adopt policy, I get errors like Sympaval had > >> (in > >> this thread: > >> http://lua.2524044.n2.nabble.com/Remove-an-object-from-the-lua-state-tp75 > >> 83 > >> 423p7583425.html). He didn't manage to get adopt working when binding, > >> but > >> rather chose to instead use it with using call_function. > >> > >> Same as him -- I get errors like this, when trying to use adopt(_2) in a > >> def(): > >> > >> .../boost/include/boost/preprocessor/iteration/detail/local.hpp:37:9: No > >> member named 'consumed_args' in 'luabind::detail::adopt_policy<2, > >> void>::only_accepts_nonconst_pointers' > >> .../boost/include/boost/preprocessor/iteration/detail/local.hpp:37:9: No > >> member named 'converter_postcall' in 'luabind::detail::adopt_policy<2, > >> void>::only_accepts_nonconst_pointers' > >> .../addons/ofxLua/src/luabind/luabind/detail/call.hpp:295:48: No member > >> named 'apply' in 'luabind::detail::adopt_policy<2, > >> void>::only_accepts_nonconst_pointers' > >> > >> And when I try to use it with call_function: > >> > >> .../addons/ofxLua/src/luabind/luabind/detail/call_function.hpp:200:20: No > >> member named 'match' in 'luabind::detail::adopt_policy<0, > >> void>::only_accepts_nonconst_pointers' > > > > The struct name "only_accepts_nonconst_pointers" is meant as an error > > message: adopt only works with non-const pointers (meaning that the > > adopted type must be both a pointer and a non-const one). > > > > Hope I could help, > > Christian ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ luabind-user mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/luabind-user |
In reply to this post by Glen F
On Tuesday 23 July 2013, at 12:00:29, Glen Fraser <[hidden email]> wrote:
> > The struct name "only_accepts_nonconst_pointers" is meant as an error > > message: adopt only works with non-const pointers (meaning that the > > adopted type must be both a pointer and a non-const one). > > Thanks, Christian -- I saw that, but I don't know how to fix it. Presumably > this is related to the fact that the object I'm trying to "adopt" is held > in a smart pointer (boost::shared_ptr). But I haven't declared the > smart_ptr as const anywhere… > > I declare my class binding like this: > > class_<Actor, Actor_wrapper, boost::shared_ptr<Actor> >("Actor") > .def(constructor<const string &>()) > .def("draw", &Actor::draw, &Actor_wrapper::default_draw) > ]; > > And the function I'm trying to call from C++ is like this: function: void bindLuaPart() { luabind::wrapped_self_t& wrapper = luabind::detail::wrap_access::ref(*this); if (wrapper.m_strong_ref.is_valid()) { LOG_W("Double call to wrap_Component::bindLuaPart"); return; } wrapper.get(wrapper.state()); wrapper.m_strong_ref.set(wrapper.state()); } This is highly dependent on implementation details though, but it works at least with the original luabind. ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ luabind-user mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/luabind-user |
Okay, thanks. I wasn't 100% sure where you meant I should put this code -- i.e. where you call your bindLuaPart(). In the wrapper object's constructor?
What I tried is this: when I add a new object (wherever it comes from) to my C++ container, I run a method based on your code below -- if the object being added to my C++ container is based on the Lua wrapper class (tested using dynamic_cast), then I get its luabind wrapped_self_t and set its "strong ref" as in your code. This seems to work, thanks! I hope this "fix" (hack?) remains more or less valid for future updates to luabind (if there ever are any ;-). Can you explain what this is doing? I guess it just creates a strong reference to the Lua object, so it doesn't get garbage collected? Do I need to do anything specific if the C++ object gets deleted (e.g. in its destructor), to release this strong reference to the Lua-side object? Should I create a matching function, that calls reset() on its m_strong_ref? Thanks, Glen. On Jul 23, 2013, at 12:20 PM, Christian <[hidden email]> wrote: > On Tuesday 23 July 2013, at 12:00:29, Glen Fraser <[hidden email]> wrote: >>> The struct name "only_accepts_nonconst_pointers" is meant as an error >>> message: adopt only works with non-const pointers (meaning that the >>> adopted type must be both a pointer and a non-const one). >> >> Thanks, Christian -- I saw that, but I don't know how to fix it. Presumably >> this is related to the fact that the object I'm trying to "adopt" is held >> in a smart pointer (boost::shared_ptr). But I haven't declared the >> smart_ptr as const anywhere… >> >> I declare my class binding like this: >> >> class_<Actor, Actor_wrapper, boost::shared_ptr<Actor> >("Actor") >> .def(constructor<const string &>()) >> .def("draw", &Actor::draw, &Actor_wrapper::default_draw) >> ]; >> >> And the function I'm trying to call from C++ is like this: > Sorry, I hit accidentaly sent my message before it was finished, here is the > function: > > void bindLuaPart() > { > luabind::wrapped_self_t& wrapper = > luabind::detail::wrap_access::ref(*this); > if (wrapper.m_strong_ref.is_valid()) { > LOG_W("Double call to wrap_Component::bindLuaPart"); > return; > } > wrapper.get(wrapper.state()); > wrapper.m_strong_ref.set(wrapper.state()); > } > > This is highly dependent on implementation details though, but it works at > least with the original luabind. > > ------------------------------------------------------------------------------ > See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > luabind-user mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/luabind-user ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ luabind-user mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/luabind-user |
On Sunday 28 July 2013, at 20:33:12, Glen Fraser <[hidden email]> wrote:
> Okay, thanks. I wasn't 100% sure where you meant I should put this code -- > i.e. where you call your bindLuaPart(). In the wrapper object's > constructor? No, that would theoretically be ideal, but unfortunately, at this point the normal (weak) reference (wrapped_self_t) is not initialized, so this does not work. > What I tried is this: when I add a new object (wherever it comes from) to my > C++ container, I run a method based on your code below -- if the object > being added to my C++ container is based on the Lua wrapper class (tested > using dynamic_cast), then I get its luabind wrapped_self_t and set its > "strong ref" as in your code. That's approximately the way I use it (in my case, the method is called from Lua, because at this point I know which class is wrap_base derived. But this might be different in your case). > This seems to work, thanks! I hope this "fix" (hack?) remains more or less > valid for future updates to luabind (if there ever are any ;-). > > Can you explain what this is doing? I guess it just creates a strong > reference to the Lua object, so it doesn't get garbage collected? Yes. This means that you need to delete/destroy the object from C++ to avoid memory leaks, the object references itself in a way so that the Lua GC does not see the cycle (intentionally). > Do I need to do anything specific if the C++ object gets deleted (e.g. in its > destructor), to release this strong reference to the Lua-side object? > Should I create a matching function, that calls reset() on its > m_strong_ref? No, that is not necessary. The strong reference is stored in the wrap_base class (as a Lua registry reference using a RAII wrapper around luaL_ref/unref), which means that is destroyed (which has the same effect as calling reset() on it) in the destructor automatically. > Thanks, > Glen. You're welcome, Christian PS: Sorry that my last answer was so garbled ;) > On Jul 23, 2013, at 12:20 PM, Christian <[hidden email]> wrote: > > On Tuesday 23 July 2013, at 12:00:29, Glen Fraser <[hidden email]> wrote: > >>> The struct name "only_accepts_nonconst_pointers" is meant as an error > >>> message: adopt only works with non-const pointers (meaning that the > >>> adopted type must be both a pointer and a non-const one). > >> > >> Thanks, Christian -- I saw that, but I don't know how to fix it. > >> Presumably this is related to the fact that the object I'm trying to > >> "adopt" is held in a smart pointer (boost::shared_ptr). But I haven't > >> declared the smart_ptr as const anywhere… > >> > >> I declare my class binding like this: > >> class_<Actor, Actor_wrapper, boost::shared_ptr<Actor> >("Actor") > >> .def(constructor<const string &>()) > >> .def("draw", &Actor::draw, &Actor_wrapper::default_draw) > >> ]; > >> > >> And the function I'm trying to call from C++ is like this: > > Sorry, I hit accidentaly sent my message before it was finished, here is > > the function: > > > > void bindLuaPart() > > { > > > > luabind::wrapped_self_t& wrapper = > > > > luabind::detail::wrap_access::ref(*this); > > > > if (wrapper.m_strong_ref.is_valid()) { > > > > LOG_W("Double call to wrap_Component::bindLuaPart"); > > return; > > > > } > > wrapper.get(wrapper.state()); > > wrapper.m_strong_ref.set(wrapper.state()); > > > > } > > > > This is highly dependent on implementation details though, but it works at > > least with the original luabind. > > > > -------------------------------------------------------------------------- > > ---- See everything from the browser to the database with AppDynamics > > Get end-to-end visibility with application monitoring from AppDynamics > > Isolate bottlenecks and diagnose root cause in seconds. > > Start your free trial of AppDynamics Pro today! > > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktr > > k > > _______________________________________________ > > luabind-user mailing list > > [hidden email] > > https://lists.sourceforge.net/lists/listinfo/luabind-user > > ---------------------------------------------------------------------------- > -- See everything from the browser to the database with AppDynamics > Get end-to-end visibility with application monitoring from AppDynamics > Isolate bottlenecks and diagnose root cause in seconds. > Start your free trial of AppDynamics Pro today! > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk > _______________________________________________ > luabind-user mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/luabind-user ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ luabind-user mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/luabind-user |
Free forum by Nabble | Edit this page |