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

Subject: Re: [Boost-users] [Thread] 1.53 fails to compile working code
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2013-02-08 13:01:14

On Thu, Feb 7, 2013 at 11:46 PM, Szymon Gatner <szymon.gatner_at_[hidden]>wrote:

> 2013/2/8 Jeffrey Lee Hellrung, Jr. <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.

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.

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.

> Is the original move emulation even still needed in Thread code.

I think there are subtle differences, perhaps not all of which have been
worked out or discovered yet.

It
> seems like half on BOOST_THREAD macros try to deal with move
> semantics.
>

- Jeff