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

Subject: Re: [Boost-users] [Boost.Thread] unique_future without && ?
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-04-06 12:47:59

On Fri, Apr 6, 2012 at 9:25 AM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

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

Eh? Why not? Correct me if I'm wrong, but I don't think you have to do
anything special to return values of move-emulation-enabled types (whether
only movable or movable+copyable) and ensure the move constructor kicks in.
E.g.,

X foo() { return X(/*...*/); }
X bar() { X result(/*...*/); return boost::move(result); }

should not create spurious copies (or compiler errors) whether in C++03 or
C++11.

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()); }
>

Again, I don't think the use of the BOOST_EXPLICIT_MOVE macro is necessary
in this case. We aren't assigning the result of foo() to an existing
unique_future<int> object, we're (logically) constructing a new
unique_future<int> object, and that, AFAIK, has never been a problem with
the move emulation provided by Boost.Move.

- Jeff