Re: [boost] Composing non copyable and movable classes

Subject: Re: [boost] Composing non copyable and movable classes
From: David Abrahams (dave_at_[hidden])
Date: 2008-12-08 16:59:59

on Sun Dec 07 2008, "vicente.botet" <vicente.botet-AT-wanadoo.fr> wrote:

> ----- Original Message ----- 
> From: "David Abrahams" <dave_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Sunday, December 07, 2008 1:42 AM
> Subject: Re: [boost] Composing non copyable and movable classes
>
>
>> 
>> 
>> on Sat Dec 06 2008, "vicente.botet" <vicente.botet-AT-wanadoo.fr> wrote:
>> 
>>>
>>> The question is how to make X movable efficiently. The first way is to
>>> move each one of the movable objects one by one. This could be
>>> expensive if the number of members is high. 
>> 
>> In general it isn't high enough to justify doing anything else.  
>
> Right, in general. But if the class C has an array of Ci and the array size is known
> at runtime or as a template parameter.

... then ... ?

>>> In addition X can have also member that are not movable.
>> 
>> Do you mean "copiable but not otherwise movable,' or simply not movable?
>
> The case that impose the allocation is a member not copyable nor movable.
>>
>>> In this case the class X don't need any more that its members be
>>> movable. In order to avoid the allocation/deallocation of the
>>> respective classes Ci, it would be interesting to have a class which
>>> is not copyable and not movable and that owns the implementation
>>>
>>> class nonmovable_Ci : noncopyable {
>>>     struct implementation_data;
>>>     implementation_data data_;
>>>     // ...
>>> };
>> 
>> 
>> To justify that, moving one of the C's must be really expensive, or
>> you have to expect many, many moves of each object to balance the cost
>> of allocation.  In general, I'd consider using the small object
>> optimization to handle cases like this.
>
> If you are the designer of the class C, how can you consider using the
> small object optimization if you don't owns the classes Ci.

I don't understand the question.  You just do it.  See boost::function.

>>> Except the movable support, the nonmovable_Ci class share with Ci the
>>> same functionality. But is not related to Ci by inheritance. Both
>>> classes model a common concept. Of course this can not be applied if
>>> the implementation_data must be hidden in some .cpp file (pimpl
>>> idiom).
>> 
>> This feels like overgeneralizing.  Unless otherwise justified, every
>> type should have value semantics, i.e., should be movable and copiable.
>
> nonmovable_Ci could also be copyable and movable, call them other_Ci,
> but these operations could be expensive, i.e. other_Ci is intended to
> not be copied nor moved.

Again, this sounds like overgeneralizing.  There's no point in
optimizing for use cases that might not even exist.  Move should never
be expensive.  If you have an expensive move, you've almost certainly
done something wrong.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com