Re: [Boost-users] boost::container::vector fails to compile with C++03 compiler

Subject: Re: [Boost-users] boost::container::vector fails to compile with C++03 compiler
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-10-26 09:17:18

On Fri, Oct 26, 2012 at 4:00 AM, mark pashley
<mark.pashley_at_[hidden]>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