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-07 14:27:15

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

>  Le 06/04/12 18:47, Jeffrey Lee Hellrung, Jr. a écrit :
>
> 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); }
>
>   Yes, this works well. But here we don't return a rvalue, isn't it?
>

It shouldn't make a difference. The original foo bar example should work as
well.

 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_EXPLICIT_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.
>
> Hi Jeff,
>
> you are right on most of the points with most of the compilers. But see
> the results of Boost.Move with Sun. Here the use of BOOST_EXPLICIT_MOVE
> helps a lot without the need of declaring a local variable.
>

Which results are you referring to? What do you mean by "helps a lot"? I
wasn't aware that Sun had issues with C++03 move emulation. What specific
C++03 feature is Sun failing to implement?

- Jeff