C++11 / VS2010 : Returning containers of uncopyable but movable objects

Question

Consider the following code:

#include <vector>
#include <boost/noncopyable.hpp>

struct A : private boost::noncopyable
{
  A(int num, const std::string& name)
    : num(num),
      name(name)
  {
  }

  A(A&& other)
    : num(other.num),
      name(std::move(other.name))
  {
  }

  int num;
  std::string name;
};

std::vector<A> getVec()
{
  std::vector<A> vec;
  vec.emplace_back(A(3, "foo"));
  // vec.emplace_back(3, "foo"); not available yet in VS10?

  return vec; // error, copy ctor inaccessible
}

int main ( int argc, char* argv[] )
{
  // should call std::vector::vector(std::vector&& other)
  std::vector<A> vec = getVec();

  return 0;
}

This does not compile under VS2010 because obviously A is noncopyable and thus std::vector<A> cannot be copied. Accordingly I cannot return a std::vector<A> from a function.

However it doesn't feel right to me that this sort of thing is not possible considering the concept of RVO. If Return Value Optimization was applied here, copy construction could be omitted and the call to getVec() would be valid.

So what would be the proper way to do this? Is this possible at all in VS2010 / C++11?

RVO does not remove the requirement that things be copyable. — juanchopanza, Jul 23 '12 at 08:06
The order of the data members in your member initialization lists (first `num`, then `name`) do not match the order of the declarations of the data members at the bottom of the class (first `name`, then `num`). In general, this can lead to very surprising bugs, so I would always strife to make the orders consistent. — fredoverflow, Jul 23 '12 at 08:17
Also, `std::vector vec = getVec();` is *not* an assignment, but an *initialization* (copy initialization, to be exact). — fredoverflow, Jul 23 '12 at 08:18
Try adding a move assignment operator. That makes it compile for me in GCC. (though my error is in a different place) — Benjamin Lindley, Jul 23 '12 at 08:19
@FredOverflow: You are right about those two things, thanks. Fixed now, since it doesn't have anything to do with the actual question. — Opossum, Jul 23 '12 at 08:25

score 11 · Accepted Answer · edited May 23 '17 at 12:26

11

If return vec; does not compile, VS2010 does not support move semantics fully yet. Normally, automatic variables are moved implicitly if returned from a function. Use return std::move(vec); as an interim workaround, and make a note in your head to get rid of the std::move in the future.

A full explanation can be found in this FAQ answer under the headline "Moving out of functions".

Also, your two-argument constructor makes a copy of the string argument which is passed by reference-to-const. I would suggest taking the argument by value instead and moving it into the member:

A(int num, std::string name) : num(num), name(std::move(name)) { }

This way, you minimize the number of necessary copies. See Want Speed? Pass by Value for details.

Also, since your move constructor doesn't do anything special, you can default it:

A(A&& other) = default;

This makes it more robust in the face of changes. Bugs seldomly hide in the code you don't write :)

edited May 23 '17 at 12:26

Community

1
1

answered Jul 23 '12 at 08:21

fredoverflow

256,549
94
388
662

+1 for pointing out that it's a VS2010 issue. However, std::move does not fix the problem. Although, as Benjamin Lindley stated in the comments, adding a move assignment operator does indeed fix it for VS2010. – Opossum Jul 23 '12 at 08:32
@Opossum Really? Why does assignment matter? `std::vector vec = getVec();` is not an assignment. – fredoverflow Jul 23 '12 at 08:33
Well I guess the vector's elements are moved using the move assignment operator. Adding `A::A& operator=(A&& other)` makes it compile. – Opossum Jul 23 '12 at 08:35
@FredOverflow: I don't know what error he was getting, but mine was with the usage of emplace_back, not with returning the object or the initialization in main. Adding the move assignment operator fixed it. – Benjamin Lindley Jul 23 '12 at 08:36
Strangely enough, emplace_back() worked fine for me. The issue was returning a `std::vector`. The error was `error C2248: 'boost::noncopyable_::noncopyable::operator =' : cannot access private member` when returning `vec`. Changing the return type to void and not returning anything works fine even without an move assignment operator. – Opossum Jul 23 '12 at 08:43
Also the `= default` keyword doesn't seem to have been implemented in VS2010 yet. Man, I can't wait for VS2012. – Opossum Jul 23 '12 at 08:48
3

@Opossum Well, then keep waiting, VS2012 doesn't bring it either. It doesn't bring many new things, not even such rather simple things like defaulted and deleted functions or delegating and inheriting constructors. – Christian Rau Jul 23 '12 at 09:04

Nicol Bolas · Answer 2 · 2012-07-23T08:33:21.577

However it doesn't feel right to me that this sort of thing is not possible considering the concept of RVO.

Elision, the general term for stuff like named return value optimization, is an optimization. It is not required. The specification allows it, but doesn't force any implementation to do it even when it is allowed to.

As such, to enforce consistency between compilers that allow elision and those that don't, if elision is allowed by an operation, the compiler must still verify that the copy/move being elided would be possible given the current state of the code. So if a copy/move constructor is not accessible, the operation fails even if the compiler won't actually call it.

In this case, Visual Studio 2010 seems to be kind of confused in this regard. It does recognize that return vec; should move from vec. However, it seems that VS2010's std::vector implementation needs a move assignment operator to move; without one, it will attempt to copy.

Wrong, normally the vector should be automatically moved in the function. — Xeo, Jul 23 '12 at 08:12

C++11 / VS2010 : Returning containers of uncopyable but movable objects

2 Answers2

Linked