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 12:10:11

On 18/05/2010 17:22, vicente.botet wrote:
>> 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?

Could be, but so many things are convertible to an rvalue...

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

I should, because it has real-world use cases.

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

Ok. I'll remove it.

> Doesn't the metafunction solve these issues?

How?

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

Yes, but if move them from Boost.Move to Boost.TypeTraits we can break 
some code. So Boost.Move should maintain some backwards compatibility, 
at least, for some time.

Best,

Ion