On Fri, Oct 26, 2012 at 4:00 AM, mark pashley
It appears that this is a limitation as explained here:
http://www.boost.org/doc/libs/1_51_0/doc/html/move/emulation_limitations.htm...
This is indeed the issue. Basically, if struct data { boost::container::vector<int> x; }; then data turns out not to be const-assignable in C++03, due to the existence of a vector::operator=(vector &) overload rather than vector::operator=(vector const &). To get things functional, all you should have to do is explicitly define a data::operator=(data const &) (which does memberwise assignment), but to enable move semantics (which would be desirable if you had a boost::container::vector<data> as in your snipped example) you would indeed need to define a move constructor and move assignment operator (and default constructor if needed; I think you can get away with using the compiler-generated copy constructor). I would consider this a usability problem as it's error-prone (adding another member to the data struct but forgetting to include it in any or all of the move constructor or copy/move assignment operators is entirely possible) and tedious. This is why I've created macros to automate the generation of this boilerplate (and expand to nothing or the "= default" versions in C++11), and may be something Ion should consider adding. E.g., template< class First, class Second > struct pair { First first; Second second; BOOST_MOVABLE_COPYABLE_MEMBERWISE( typename pair, (( First )( first )) (( Second )( second )) ) }; Incidentally, with some additional complexity, the above macro can enable the move emulation machinery in C++03 iff either of First or Second is movable. If desired, I can see about packaging these up for inclusion in Boost.Move. - Jeff