Subject: Re: [boost] [thread] Boost.Thread defines boost::move which conflicts with Boost.Move
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-01-09 17:46:38
On Mon, Jan 9, 2012 at 2:17 PM, Vicente J. Botet Escriba <
>> I have tested the basic functionality on a number of compilers, but
>>>> there are probably still some bugs in the patched code.
>>>> The patch contains a number of known problems that may be worth
>>>> discussing:1) Explicit move() and copy() calls:boost::thread and
>>>> boost::packaged_task both have templated constructors that take an
>>>> rvalue reference to a functor (which they move or copy as
>>>> appropriate). Templates parameters cannot be deduced to a type that is
>>>> only reachable through an conversion operator. Template constructors
>>>> can also never be explicitly instansiated. (As far as I know.) This
>>>> means that the overloads that are used in the definitions of
>>>> BOOST_COPYABLE_AND_MOVABLE types (BOOST_RV_REF(type),
>>>> BOOST_CATCH_CONST_RLVALUE(**type), type&), are not matched for rvalue
>>>> objects (in C++03 mode). Example:
>>>> //In C++11 the `CopyableAndMovableFunctor` would be //moved
>>>> into the thread. //In C++03 this does not compile.
>>>> Hrr, this is really a bad new. Could you create a Boost.Move ticket if
>>> limitation is not documented and a ticket doesn't exists already for this
>>> It's a known limitation in Boost.Move, AFAIK. The above change should
>> address this issue.
>> Could you point where in the doc it is described or to the Trac ticket?
Looking through the documentation, in short, no I can't find any mention of
this limitation. Let me see if I understand it correctly, though. One has
the following constructor overloads:
template< class F > thread(BOOST_RV_REF( F ) f);
template< class F > thread(BOOST_CATCH_CONST_RVALUE( F ) f); // what is
template< class F > thread(F& f);
to, ideally, bind the temporary functor to an emulated rvalue reference.
But I gather the above won't even compile since 1) the template parameter F
cannot be deduced in the first 2 constructor overloads (the compiler won't
apply conversions); and 2) a temporary cannot bind to the F& overload.
If the above is all accurate, then I wonder where the above 3 constructor
overloads came from in the first place...?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk