Boost logo

Boost :

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!


Hervé Brönnimann
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]
> [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:
> listinfo.cgi/boost

Boost list run by bdawes at, gregod at, cpdaniel at, john at