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-31 11:57:43

On 31/05/2010 13:55, Thomas Klimpel wrote:
>> If I understand correctly, optimal move emulation for
>> boost::container::vector is the best choice if we ignore the effect on
>> (future) enclosing classes.  Are you/we necessarily against just going
>> with this, documenting the fact that enclosing classes will have to
>> deal with the non-standard compiler-generated copy assignment operator
>> (either by defining it explicitly, perhaps conditionally; or wrapping
>> member vars in a wrapper, also perhaps conditionally)?
>
> I'm not necessarily against it. But I would like to hear Ion's opinion on this.

My personal opinion is that forcing enclosing classes to define a copy 
constructor with const T & signature is an acceptable limitation for the 
move emulation, specially if this is well-documented. The good part now 
is that for those classes that don't need to reuse existing resources 
operator=(T t) is available. It's a shame we have some side-effects, but 
catching rvalues is a quite important (think about adding strings, 
etc...) feature for move semantics.

>> We don't have any backwards compatibility concerns, since
>> boost::container::vector is not actually released yet, right?
>
> Yes and no. If I understand it correctly, boost::container::vector
> will be the successor of boost::interprocess::vector (=
> boost::interprocess_container::vector). And these interprocess
> containers are meant as replacements for stl containers with extended
> allocator support, as required for boost.interprocess. Changing the
> behavior of the copy assignment operator might make them less
> suitable as replacements for stl containers.

Yes and no ;-) To avoid breaking Interprocess code, I could maintain 
current guarantees in Boost.Interprocess even if Boost.Container is the 
underlying implementation for Interprocess containers or just maintain 
the old interprocess implementation code accessible with a macro for 
those that don't want to change a line of code.

The good part of the copy assignment issue is that it triggers a 
compilation error, and not a runtime-error, so even a source breaking 
change occurs in Interprocess because Interprocess containers are 
changed to be just typedefs for Boost.Container containers, that change 
wouldn't provoke any disaster.

Best,

Ion