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-08 06:01:00

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

Best,
Vicente