On Mon, Apr 9, 2012 at 4:54 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> 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@wanadoo.fr> 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