Boost logo

Boost :

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at