Re: [Boost-users] problems with Boost.Thread on VS10

Subject: Re: [Boost-users] problems with Boost.Thread on VS10
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-04-09 20:10:19

On Mon, Apr 9, 2012 at 4:54 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

>  Le 10/04/12 01:24, Jeffrey Lee Hellrung, Jr. a écrit :
>
> On Mon, Apr 9, 2012 at 3:14 PM, Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]> wrote:
>
>>
>>   There are yet some problems on the Boost.Thread implementation or with
>> the compilers implementation.
>>
>> When I want to pass functor, as in
>>
>> A a(5);
>> boost::packaged_task<int> pt(a);
>>
>> the constructor used is packaged_task(F&& f) and I will expect
>> packaged_task(F const& f) to be use for.
>> Are my expectations correct?
>>
>
> Well...no, apparently your expectations are not correct. But that's
> slightly beside the point. I think the correct fix here is to remove the
> packaged_task(F const &) overload entirely, since the packaged_task(F&&)
> overload already covers it (that's part of the entire design of "templated
> rvalue references", to capture both rvalues *and* lvalues). Then
> instantiate task_object with something like remove_cv<
> remove_reference<F>::type >::type, and use boost::forward<F>(f) to pass the
> function object down to the task_object constructor.
>
> Yeah, this is the point. packaged_task(F const &) overload was not used
> never, and task_object  was instantiated as task_object<R,A&>. I have a
> patch that seems to work (see below I have not used remove_cv yet, but I
> agree it should be needed to take care of const functors).
>

Okay, now it's starting to click what you were doing before. I might've
been confusing packaged_task (where F is "free") with task_object (where F
is "bound" already). I should've looked at it closer; sounds like you had
already figured out the correct fix.

The overload
>
>         explicit packaged_task(R(*f)()):
>             task(new
> detail::task_object<R,R(*)()>(f)),future_obtained(false)
>         {}
>
> seems necessary because otherwise the task_object is instantiated with
> <R,R()> which is not what we want.
> Do you have an hint on how simplify this?
>

Okay yeah I wasn't sure why you needed this overload, thanks for
clarifying. I guess when constructing a packaged_task with a function name,
and you don't explicitly use the address-of operator (&), F gets bound as a
function reference? Probably easiest to just explicitly use a separate
constructor as above and document its necessity.

>   The test futures/packaged_task/alloc_ctor_pass.cpp gives this context.
>>
>> Thanks for your patience and perseverance.
>>
>
> And thank you for clarifying the issue for me!
>
>
>  Please, could you check the patch and see if there is something that can
> be improved.
>

Yeah that looks about what I would've suggested. Just add, like you said,
the remove_cv's.

Thanks for all,
> Vicente
>

[snip patch]

Sorry for the noise, thanks for being patient,

- Jeff