Re: [Boost-users] [Thread] 1.53 fails to compile working code

Subject: Re: [Boost-users] [Thread] 1.53 fails to compile working code
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-02-08 16:31:55

Le 08/02/13 19:01, Jeffrey Lee Hellrung, Jr. a écrit :
> On Thu, Feb 7, 2013 at 11:46 PM, Szymon Gatner 
> <szymon.gatner_at_[hidden] <mailto:szymon.gatner_at_[hidden]>> wrote:
>
>     2013/2/8 Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung_at_[hidden]
>     <mailto:jeffrey.hellrung_at_[hidden]>>:
>     >
>     > This looks like an error in the future_traits<T>::init overload
>     set...it's
>     > missing an overload that a T const & can bind to (in the second
>     argument).
>     >
>     > Also, I think it would be an improvement if
>     set_value_at_thread_exit was
>     > able to catch rvalues as emulated rvalue references (when true
>     rvalue
>     > references are unavailable) rather than as
>     lvalue-reference-to-const.
>     >
>
>     Yes indeed, there is an overload resolution ambiguity.
>
>
> Strictly speaking, it isn't an ambiguity that's causing the compiler 
> failure, it's that the eligible overload set is empty.
You are right.
>
>     I guess movable
>     / emulation stuff in Thread is more difficult to manage since it
>     maintains 2 move emulations (original one from Thread and Move).
>
>
> Yes :( I can imagine the maintenance nightmare for Vicente.
I don't know if I've missed something really relevant of Boost.Move, but 
only with this emulation I have a lot of difficulties as not only 
Boost.Thread defines Movable types, but it offers interfaces with 
functions that can be movable and that accept copyable/movable arguments 
and that can return movable types.
>
>     Move
>     already provides BOOST_RV_REF(T) macro which is T&& on compiler that
>     support it and rv<T>& when emulating and this imho is the argument
>     type future_traits<T>::init() should use to disambiguate.
>
>
> Ideally, but the present implementation of set_value_at_thread_exit 
> precludes init capturing by rvalue reference, AFAICT.
Jeffrey I believe the problem comes from the fact that I have added two 
overloads for set_value_at_thread_exit and the copy overload is 
instantiated when using a move-only class

             void set_value_at_thread_exit(const T & result_){...} // 
this instantiation with a MoveOnly class results in a compiler error
             void set_value_at_thread_exit(BOOST_THREAD_RV_REF(T) 
result_){...}

>     Is the original move emulation even still needed in Thread code.
>
Using Boost.Move is some kind of breaking change respect to the old one. 
I'm fully for discarding the old emulation, but I would like to hear 
what others thing.
>
> I think there are subtle differences, perhaps not all of which have 
> been worked out or discovered yet.
>
>
I don't think the problem comes from trying to manage 2 move emulations, 
but of course I might be wrong.

anyway, I will see if I can fix it or otherwise I would restraint the 
use of _at_thread_exit functions to the compilers supporting them 
completely.

Thanks for the report,
Vicente