Re: [Boost-users] [Boost.Thread] unique_future without && ?

Subject: Re: [Boost-users] [Boost.Thread] unique_future without && ?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-04-06 12:25:43

Le 06/04/12 09:20, John M. Dlugosz a écrit :
> My code needs to be compatible with a platform that doesn't have 
> rvalue references available, for the time being.
Which platform and compiler?

> I've avoided explicit uses of move and made my && arguments fall back 
> to const&.
> But I'm not sure about returning a unique_future.  I see that 
> unique_future<T> has a special move-the-guts type, with an implicit 
> conversion operator and a constructor.  But do I need to do anything 
> special to declare a function returning one, and likewise the return 
> statement itself?  The code in packaged_task ( unique_future<R> 
> packaged_task<R>::get_future() ) is not conditionally compiled based 
> on BOOST_NO_RVALUE_REFERENCES, so I'm supposing that it just works by 
> itself.  Is that correct?
>
> But maybe it only works by itself in some cases?  In that code, the 
> return statement names a constructor directly.
>                 return unique_future<R>(task);
>
> In my code, I'm returning a unique_future that I already made 
> somewhere else (actually, the result of another function call) so it 
> would be wanting to call the copy constructor, I would think.
>
> So if I write
>     unique_future<int> foo();
>     unique_future<int> bar() { return foo(); }
>
> what _should_ happen is that the existing value uses a user-defined 
> conversion to construct the "copy", right?  So I should expect this to 
> work correctly if the thing I'm returning is already exactly the right 
> type, as well as when naming the constructor directly.
>
The released implementation doesn't manage well returning rvalue.

The trunk has been refactored a lot of code and it allows to manage with 
rvalue references. Could you tru with the trunk

     unique_future<int> foo();
     unique_future<int> bar() { return BOOST_EXPLICT_MOVE(foo()); }

HTH,
Vicente