On Thu, Mar 20, 2014 at 11:08 PM, Lane < software.research.development@gmail.com> wrote:
I'm having a problem passing a pointer as an arg via boost::bind and was hoping anyone could help out. I was able to pass 'a' just fine, but the second arg 'b' I'm having a problem with.
Here is what I have.
--
namespace NS {
class MyThread {
int doIt(NS::A a, B *b);
// ...
A a;
B *b = new B();
NS::MyThread f_thread;
boost::thread workerThread(boost::bind(&NS::MyThread::doIt, &f_thread,
boost::ref(a), boost::ref(b)));
Any help much appreciated.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
What exactly is the problem you are having? A compilation issue? A runtime issue? Various things that may help: - boost::ref() returns an object that has a reference to your object. That object has a conversion operator overload for returning a reference to the original type. - Using boost::ref() with a pointer would only be useful if the pointer address needs to be changed. That does not appear to be the case in this situation. - Using boost::ref() with a function that copies its arguments is usually not going to do what you want (it will save one copy, if that was the goal). - The callback on boost::thread is launched asynchronously - Unlikely to be an issue since both are on the stack, but using boost::ref(a) means the object is never copied by boost::bind. So the reference must remain valid until boost::thread calls invokes boost::bind which will call your function (dolt). Since the function takes the argument by copy, the stack object can be cleared after the call to dolt is made (a bit precarious even with proper thread synchronization). - Boost::thread objects no longer automatically detaches joinable threads upon destruction. - A join or detatch must be done before destruction. It was not clear from the example whether this was being done. - Boost thread constructor can throw - Smart pointer usage is always encouraged, which is unlikely to be related to this issue but worth mentioning just in case. Lee