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-08 11:18:23

On Sun, Apr 8, 2012 at 5:46 AM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> Le 07/04/12 11:11, John M. Dlugosz a écrit :
>
>> On 4/6/2012 11:59 AM, Vicente J. Botet Escriba wrote:
>>
>>> As you are using std::move, &&, ... why not using directly the C++11
>>> Thread library
>>> provided with the compiler?
>>>
>>
>> 1) VS10 has && and std::move, but does not have the C++11 threading
>> library.
>>  1b) A naive implementation (just starts a new OS thread) is not wanted.
>>  1c) but, an overly heavy implementation is not wanted either (i.e VS11
>> beta), because of additional dependencies in the program to distribute.
>> 2) In the final code, the && will be optional, to avoid copies on
>> compilers that support it, but must work with compilers that don't.
>> 3) I need to preserve semantics of the code I'm replacing with modern C++
>> forms.
>>
> OK, I see.
>
>>
>>
>>> BTW, Boost.Thread could not implement async using Boost, as Boost.Tuple,
>>> Boost.Bind
>>> Boost.Fusion (Tuple) because these libraries dont manage with rvalue
>>> references.
>>>
>>
>> I don't understand how that applies to my compiler problem.  It's telling
>> me that
>>
>>           task_object(F const& f_);   // << refers to look here
>>           task_object(F&& f_);         // <<<< Error here
>>
>> are not a valid overloading set and instead conflict.
>>
>>  Sorry, I misunderstood your message.
>
> After applying the following patch your example compiles. Please could you
> try it?
>
> Could you also add a Trac ticket so that this is tracked?
>
> HTH,
> Vicente
>

Vicente,

It looks like you're just removing the task_object::task_object(F const &)
overload. Seems strange that this overload existed but was/is never
actually suppose to be used. ...except when F is a function pointer, I
guess???

I sent a message to the list recently observing that one problem was the
binding of F to be an lvalue reference (according to the error message,
AFAICS), meaning that "F const &" and "F&&" are exactly the same type.
Perhaps this behavior should be addressed directly?

- Jeff

Index: future.hpp
> ==============================**==============================**=======
> --- future.hpp    (revision 77816)
> +++ future.hpp    (working copy)
> @@ -1695,7 +1695,10 @@
>             task_base<R>
>         {
>             F f;
> -            task_object(F const& f_):
> +//            task_object(F const& f_):
> +//                f(f_)
> +//            {}
> +            task_object(R(*f_)()):
>                 f(f_)
>             {}
>  #ifndef BOOST_NO_RVALUE_REFERENCES
> @@ -1703,6 +1706,7 @@
>                 f(f_)
>             {}
>  #else
> +
>  #if defined BOOST_THREAD_USES_MOVE
>             task_object(boost::rv<F>& f_):
>                 f(boost::move(f_))
> @@ -1736,7 +1740,10 @@
>             task_base<void>
>         {
>             F f;
> -            task_object(F const& f_):
> +//            task_object(F const& f_):
> +//                f(f_)
> +//            {}
> +            task_object(void(*f_)()):
>                 f(f_)
>             {}
>  #ifndef BOOST_NO_RVALUE_REFERENCES
> @@ -1797,10 +1804,10 @@
>         {}
>
>         // construction and destruction
> -        template <class F>
> -        explicit packaged_task(F const& f):
> -            task(new detail::task_object<R,F>(f)),**
> future_obtained(false)
> -        {}
> +//        template <class F>
> +//        explicit packaged_task(F const& f):
> +//            task(new detail::task_object<R,F>(f)),**
> future_obtained(false)
> +//        {}
>         explicit packaged_task(R(*f)()):
>             task(new detail::task_object<R,R(*)()>(**
> f)),future_obtained(false)
>         {}
>
> ______________________________**_________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/**mailman/listinfo.cgi/boost-**users
>