Re: [Boost-users] [boost][thread] Future returning 0xfeeefeee

Subject: Re: [Boost-users] [boost][thread] Future returning 0xfeeefeee
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2013-04-07 17:23:54

On Sun, Apr 7, 2013 at 10:48 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

>  The main difference I see is the way the function is obtained:
>
>
>
> When using vector the 'work' variable is a reference to the queue back,
> there is no move no assignment of function<void()> objects.
>
>       auto work = work_queue.back();
>       work_queue.pop_back();
>
> When using tbb the 'work' variable is default constructed and copied using
> try_pop (see below).
>
>

>  std::function<void()> work;
>  while( !end_of_work && m_task_queue.try_pop( work ) )
>
> I suspect that there could be an issue with the Boost.Thread
> implementation here.
>
>
My understanding is that

 auto work = work_queue.back();

Here 'work' a copy of the back element, not a reference.
Visual Studio and answers to this question
http://stackoverflow.com/questions/7138588/c11-auto-what-if-it-gets-a-constant-reference

seem to confirm that it is the intended behaviour of auto (which I have
followed so far, so don't have much doubts but maybe I'm wrong).

So to me the difference is that with the vector the 'work' object is
copy-initialized while with WorkQueue it is just copied by assignation (as
the documentation you quote state).

I'm not sure to follow what kind of issue Boost.Thread would have with the
code you quote?

> I don't master lambdas yet: does this the following code mean that
> work_queue is taken by reference and promise by value on the pushed lambda
> object?
>
>   auto do_some_work = [&]()-> boost::future<int*>
>   {
>     auto promise = std::make_shared<boost::promise<int*>>();
>     work_queue.push_back( [=]
>
>     {
>       promise->set_value( &TRUC );
>     });
>
>     return promise->get_future();
>
>   };
>

To be more precise: 'work_queue' is taken by reference, while 'promise'
(which is a shared_ptr) is taken by copy, so yes.
The promise is not copied. I cannot move it into the lambda because lambdas
don't provide a syntax for this (yet).
Which is why I had to use a shared_ptr even if I don't like to have to pay
an allocation for this. Fortunately this will not impact my application
performance.

Joel Lamotte