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@mac.com 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