Lua › Lua C++ Bind

weak_ref issue patch

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Max McGuire

weak_ref issue patch

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.

Max

--
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

weak_ref.cpp (5K) Download Attachment

Glen F

Re: weak_ref issue patch

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.

Glen F

Re: weak_ref issue patch

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?
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.

--
View this message in context: http://lua.2524044.n2.nabble.com/weak-ref-issue-patch-tp7581558p7650973.html
Sent from the Lua C++ Bind mailing list archive at Nabble.com.

------------------------------------------------------------------------------
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

Glen F

Re: weak_ref issue patch

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:

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

…

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
…

(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?
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.

Christian-2

Re: weak_ref issue patch

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

Glen F

Re: weak_ref issue patch

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:

    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
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

Christian-2

Re: weak_ref issue patch

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]>

wrote:

> >> 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

Christian-2

Re: weak_ref issue patch

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:

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

Glen F

Re: weak_ref issue patch

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

Christian-2

Re: weak_ref issue patch

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