On Fri, Oct 26, 2012 at 4:00 AM, mark pashley <mark.pashley@btinternet.com> wrote:
It appears that this is a limitation as explained here:

http://www.boost.org/doc/libs/1_51_0/doc/html/move/emulation_limitations.html#move.emulation_limitations.assignment_operator

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