I was surprised this didn\'t show up in my search results, I thought someone would\'ve asked this before, given the usefulness of move semantics in C++11:
Short answer: If a type is copyable, it should also be moveable. However, the reverse is not true: some types like std::unique_ptr
are moveable yet it doesn't make sense to copy them; these are naturally move-only types.
Slightly longer answer follows...
There are two major kinds of types (among other more special-purpose ones such as traits):
Value-like types, such as int
or vector
. These represent values, and should naturally be copyable. In C++11, generally you should think of move as an optimization of copy, and so all copyable types should naturally be moveable... moving is just an efficient way of doing a copy in the often-common case that you don't need the original object any more and are just going to destroy it anyway.
Reference-like types that exist in inheritance hierarchies, such as base classes and classes with virtual or protected member functions. These are normally held by pointer or reference, often a base*
or base&
, and so do not provide copy construction to avoid slicing; if you do want to get another object just like an existing one, you usually call a virtual function like clone
. These do not need move construction or assignment for two reasons: They're not copyable, and they already have an even more efficient natural "move" operation -- you just copy/move the pointer to the object and the object itself doesn't have to move to a new memory location at all.
Most types fall into one of those two categories, but there are other kinds of types too that are also useful, just rarer. In particular here, types that express unique ownership of a resource, such as std::unique_ptr
, are naturally move-only types, because they are not value-like (it doesn't make sense to copy them) but you do use them directly (not always by pointer or reference) and so want to move objects of this type around from one place to another.