Boost logo

Boost :

Subject: Re: [boost] [Review] Formal Review: Boost.Move
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2010-05-18 09:19:52


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk