Re: [boost] [Review] Formal Review: Boost.Move

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

On 16/05/2010 1:26, vicente.botet wrote:

> * The use of the is_movable metafunction is not clear in the
> documentation. The name let think to a concept check, that is, is T a
> model of the Movable concept? But the check is related to whether T
> is convertible to rv<T>&, and it seems you uses it in Boost.Container
> to avoid conflicts using enable_if/disable_if. Could you clarify
> this? Should is_movable be renamed to a more specific name?

Is not clear and after discussing it in previous mails, I think it 
should be present only for C++03 with another name. It detects whether a 
class implements move emulation functions. It's useful to sfinae out 
some overloads in generic functions (eg. push_back in vector, since 
vector<int> should not instantiate at all any rv<int> type).

> * Should the use of BOOST_RV_REF in template classes be protected
> with is_movable?
>
> * What returns is_movable if BOOST_ENABLE_MOVE_EMULATION is not
> defined for compilers with rvalue references?

I don't have anything in addition to Jeffrey's explantions for those. 
Thanks Jeffrey!

> * Could you add the requirements of a Movable type? Could we have a
> trait for this?

Yes, please see my previous post replying Jeffrey.

> * I don't know if the next metafunction is correct in C++0x,
> If correct, could it be used to replace the macro BOOST_RV_REF?

See Jeffrey's explanation. Adding more metafunctions would be correct if 
we find they might be useful for generic programming. But I don't know 
if rv<T> & is the correct answer for generic programming using C++0x 
(add_rvalue_reference, remove_rvalue_reference, is_rvalue_reference). We 
still don't have enough experience with both rv references and this 
emulation to know the answer.

> * BTW, why BOOST_RV_REF_2_TEMPL_ARGS and BOOST_RV_REF_3_TEMPL_ARGS
> are needed?

Preprocessor limitations, extra parens won't fix ;-)

Regarding the use of Boost.Preprocessor, I aim was to write Boost.Move 
with very few dependencies. Although support for Boost.MPL was requested 
in previous discussions, I would like to get this without header 
dependencies, but I guess Boost.TypeTraits will also depend on MPL, 
although that could be fixed because traits might go to TypeTraits.

>
> * has_nothrow_move. What are the expected some performance
> improvements.  of movable classes that specialize this to true? Could
> an example be added?

See http://permalink.gmane.org/gmane.comp.lib.boost.devel/204112

> * As the standard uses these more specific ones template<class T>
> struct has_nothrow_move_constructor;
>
> template<class T>  struct has_nothrow_move_assign;
>
> Shouldn't Boost.Move use these

Yes, at least if they are stable in the draft. And maybe they should en 
end in Boost.TypeTraits, along with has_trivial_destructor after move, 
which can be used to avoid calling destructors in containers when an 
element is moved and its destructor does not need to release any resource.

> Implementation * I would like to know the reason to don't use
> is_convertible from Boost.TypeTraits and define your own. * The same
> for identity?

Dependency issues, but I have no problem to change this.

Best,

Ion