On 16/05/2010 12:24, vicente.botet wrote:
In C++03, is_movable needs to instantiate rv<T> to detect if T is convertible to T, but for the builting types this should not work as rv<int> generate a compile error. The same applies for enums. Am I missing something?
No, is_movable<int>::value compiles perfectly and returns false. At least in my compiler.
* Should the use of BOOST_RV_REF in template classes be protected with is_movable?
I don't think this is necessary as far as using BOOST_RV_REF( T ) as a function parameter type. In C++03, that function will just simply never be instantiated if T isn't movable (because a variable of type BOOST_RV_REF( T ) would never be created).
You are right for function parameters, but for return types or typedefs we should protect the instantiation, isn"t it?
Can you put an example? Returning BOOST_RV_REF( T ) is not mentioned in the documentation, so I didn't consider this use case.
I'm hoping more generally to be specific on where we stand with throwing move constructors and, if acceptable, how we intend to support them.
If you haven't already, see David Abraham's article at C++Next [1], and the link from there to N2983.
I did, and will do again, but I think that the documentation need to explain explicitly or reference here somthing external.
Why should move emulation take care of this? Boost.Move does not care if a move constructor throws or not, IMHO. Containers should worry about this, but I can't see any Boost.Move function affected by this.
Well, this is the current state of C++0x. I will prefer Boost.Move to be close to C++0x. You, or Boost.Move can always define the more general with the specific.
Maybe all these traits should go to Boost.TypeTraits, once we define the requirements for MoveConstructible/MoveAssignable. Best, Ion