Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk