Boost logo

Boost Users :

Subject: Re: [Boost-users] [Boost.Thread] unique_future without && ?
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-04-08 11:25:46


On Sun, Apr 8, 2012 at 3:01 AM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> 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]> 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]> 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.
>

Well the accessibility of a member function never influences its position
in an overload set (AFAIK). What is *suppose* to happen in C++03 for the
above example is that the future::future(rv< future >&) overload gets
called, since a future rvalue isn't suppose to be bindable to the argument
of the (private and undefined) future::future(future&) overload. That's
clearly not happening :( I can't think of a fix other than making your
intentions very explicit as you've done above :/

Thanks for the explanation,

- Jeff



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net