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 13:05:35

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] <mailto: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?
> 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.

Best,
Vicente