On Fri, Apr 6, 2012 at 9:25 AM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> 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); }