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