Boost logo

Boost :

Subject: Re: [boost] Futures Review - Should packaged_taskbeCopyConstructible?
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2009-02-10 12:47:28

----- Original Message -----
From: "Anthony Williams" <anthony.ajw_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, February 10, 2009 6:28 PM
Subject: Re: [boost] Futures Review - Should packaged_taskbeCopyConstructible?

> "vicente.botet" <vicente.botet_at_[hidden]> writes:
>> So I've
>>> tried to move the packaged_task which don't work either because the
>>> promise is broken
>>> template<typename F>
>>> std::packaged_task<typename std::result_of<F()>::type> lazy_call(F f)
>>> {
>>> typedef typename std::result_of<F()>::type result_type;
>>> std::packaged_task<result_type> task(std::move(f));
>>> task.set_wait_callback(invoke_lazy_task<result_type>())
>>> return task;
>>> }
> Why does this not work? Is it that the callback is broken (it gets
> passed the wrong task?) If so, that's the part that needs fixing, rather
> than the copyability of packaged_task.

Sorry i was not clear. The problem is that the reference to the task

   std::packaged_task<result_type> task(std::move(f));

has been stored in the set_wait_callback. But this address is no more valable when the function returns, so when the user gets the future and call to get, the callback uses a bad address. Hoping it is clear now.

>>> What is the rationale for making packaged_task movable only? Why
>>> should not be CopyConstructible?
> If packaged_task was copyable, people would copy it and expect the copy
> to be associated with the futures they obtained from the original. Not
> necessarily deliberately, but by mistake (e.g. copying into a vector
> rather than moving). This is not the case.

Ok, I see. Anyway, I think that examples like
 template<typename F>
std::packaged_task<typename std::result_of<F()>::type> lazy_call(F f);

should be included in the library, at least as an example.


Boost list run by bdawes at, gregod at, cpdaniel at, john at