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