Le 07/04/12 20:27, Jeffrey Lee Hellrung, Jr. a écrit :

On Fri, Apr 6, 2012 at 10:05 AM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> 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@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?

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?

The following doesn't compiles with Sun compiler

 boost::future<int> f = p.get_future();


"../libs/thread/test/sync/futures/promise/alloc_ctor_pass.cpp", line 34: Error: boost::future<int>::future(boost::future<int>&) is not accessible from main().

When I force the explicit conversion it works.

      boost::future<int> f = BOOST_EXPLICIT_MOVE(p.get_future());

I guess this is because even if the copy constructor is private Sun Compiler prefers the private overload to the move constructor that needs an implicit conversion.