Boost logo

Boost :

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 <
vicente.botet_at_[hidden]> wrote:

>> 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_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.
>>>> boost::thread((**CopyableAndMovableFunctor()))
>>>> Hrr, this is really a bad new. Could you create a Boost.Move ticket if
>>> the
>>> limitation is not documented and a ticket doesn't exists already for this
>>> issue?
>>> 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);

and wishes


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...?

- Jeff

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