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

Subject: Re: [boost] [Review] Formal Review: Boost.Move
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-05-18 11:22:17

----- Original Message ----- 
From: "Ion Gaztañaga" <igaztanaga_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, May 18, 2010 3:26 PM
Subject: Re: [boost] [Review] Formal Review: Boost.Move

> 
> 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).

What about is_convertible_to_rvale?

Do you plan to add some examples that use this metafunction on the documentation? Maybe moving some examples from Boost.Container?

>> * 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!

My question was because the documentation doesn't state clearly the Jeffrey's explantions. If you will remove this metafunction for C++0x compilers, the issue is no more one.
 
>> * 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.

Ok, we will see.
 
>> * BTW, why BOOST_RV_REF_2_TEMPL_ARGS and BOOST_RV_REF_3_TEMPL_ARGS
>> are needed?
> 
> Preprocessor limitations, extra parens won't fix ;-)

Doesn't the metafunction solve these issues?

> 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.
 
I agree that some of the traits in Boost.MPL could be moved to Boost.TypeTraits. Could it be possible to reverse the dependencies?

Anyway, I don't want to start here a discusion on wether a library should or not limiting his dependencies. I want to say that just that in order to understand the code we need now to see the explicit implementation, while there is already one available on Boost.

>> * 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.

Including these on Boost.Move could allows to experiment and give an input to the standard.

Best,
Vicente