Re: [boost] [move] Library uploaded to sandbox

Subject: Re: [boost] [move] Library uploaded to sandbox
From: Hervé Brönnimann (hervebronnimann_at_[hidden])
Date: 2009-02-28 01:18:01

Hi Ion:  I've been playing with this code a bit lately, on some  
antique (pre-SFINAE) compilers.  I've sent you private emails but may  
as well post to the list to share with everyone else, and also this  
has become a bit clearer to me.

SunPro Studio 8:  The implementation of "operator rv<T>&() { return  
static_cast<rv<T>&>(*this); }" produces an infinite loop.  Replacing  
"static_cast" by "reinterpret_cast" solved the problem.

AIX xlC 8: I've run into the problem of catch-by-reference.  In the  
mailing,  you said earlier on the mailing list:

> boost::interprocess::vector<file_descriptor> v;
> push_back(const T &x);
> push_back(BOOST_RV_REF(T) x);
> Then 1 is chosen because derived to base conversion is stronger  
> than the conversion operator.

But when push_back instead is a constructor that takes a movable  
class T, as in:

     struct U : T {
          U(const T& x) : T(x) {}
          U(rv<T>& x) : T(x) {}
     };

xlC did not select the first overload, rather I obtained an ambiguity  
when trying to create U u(T(...)); because the compiler had the two  
conversion sequences:

    1. T user-conversion to rv<T>& then using second ctor.
    2. T to const T& using lvalue-to-rvalue conversion, then user  
conversion to U using first ctor, then using the implicit copy ctor.

So the ambiguity is between second ctor and implicit copy ctor, while  
the first ctor still plays a role.  I don't think this is correct  
behavior, though, and g++ does not complain about ambiguity.  Any  
explanation welcome.

Besides those two kinks, I found the whole thread enlightening.  Thanks!

Cheers,
--
Hervé Brönnimann
hervebronnimann_at_[hidden]
PS: As promised, I attach the patched move.hpp with the#ifndef  
BOOST_NO_SFINAE #else #endif branch implemented.  Testing minimal,  
but at least compiled your test example (which you offered as "A  
little example to play a bit: ...") .


On Feb 17, 2009, at 5:00 PM, Ion Gaztañaga wrote:
> Hi to all,
>
> I've uploaded a new version of the move emulation library to  
> sandbox. I've put it temporarily in "move_semantics" folder to  
> avoid overwriting current move code.  [SNIP]
>
> http://www.drivehq.com/web/igaztanaga/move_semantics.zip
>
> [SNIP] Anyway, my opinion is that we need some move library, better  
> now than later even if it's too basic, so that we can unify all  
> redundant move emulation that we already have in boost libraries. I  
> hope this is a step in the right direction.
>
> Best,
>
> Ion
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/ 
> listinfo.cgi/boost