Re: [boost] Composing non copyable and movable classes

Subject: Re: [boost] Composing non copyable and movable classes
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-12-07 07:57:58

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

>> 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.
 
>>
>> This allows the class X to allocate all the data at once.
>>
>> I think that this separation is in line with the C++ principle "you
>> don't pay for what you don't use". Any thoughts?
> 
> I think it makes me pay for a lot of complexity and for the cost of
> managing dynamically-allocated resources.  But that's just an initial
> reaction.  I'm not really sure I understand the context for what you're
> proposing.  Are you saying all classes should be designed this way,
> or... ?

Not at all. If Ci and other_Ci were available, I would use other_Ci in this case. Now if I were the author of Ci I'll provide other_Ci only if I had a concrete use case, because maintainng both classes synchronized adds complexity. How these classes, Ci and other_Ci, can be designed is another question.

Vicente