Re: [Boost-users] [Boost.Thread] unique_future without && ?

8 Apr 2012

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

Best,
Vicente