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