Short answer
because they are copyable.
Long Answer
We have first to clarify what6 "move" actually means.
Von Newman machines don't move data: thy just "copy". Data are copyed form a memory location to another. never "moved".
But at higher abstraction level data can be just pointers to other data. When you copy a pointer nullifying the copyed one, the referred data are said to be "moved" from one "owner" to another.
More generally, an operation that copies a value (lake the address contained in a pointer is) and destroys the original one setting it to a recognizable "invalid" is said to be a "move".
In term of C++ whe can distinguish different type of objects:
- The ones containing just a simple value.
- The ones containing just a simple pointer or reference that "own" what they refer
- The ones containing just a simple pointer or reference not "owing" what they refer
- The ones containing huge values.
- The ones that represent a physical entity or an operating system (more general "hosting platform") entity.
For all of this types, the concept of "copy" and "move" may have different semantic meaning, and for some of then one operation or the other may have mo meaning at all.
Now Consider type 1 objects:
int a=5; c=0;
c = a;
c = std::move(a);
what do you expect the value of a to be after the move? What about c = a+b? Should a and b be "moved" into operator+ ?
Consider now type 2 objects:
std::unique_ptr<int> pa(new int(5)), pb;
pb = std::move(pa);
Here there are two smart pointer (both of them will be destroyed on scope exit) and only one integer.
There is an operation (the delete, in this case) that can be done only once, so only one pointer must retain the "ownership" of the integer. Thsi is the case where "copy" is meaningless, and move is the only supported operation
Now consider type 3 objects:
std::list<int> lst = { 1,2,3,4 };
auto i = lst.begin();
auto j = i;
*j = *i+5;
++i;
*i = *j;
This makes perfectly sense: it just make the list to become { 6,6,3,4 }.
Iterators don't own what they refer: there may be many of them all referring the same value. Copy makes sense, but move doesn't: if we move i into j (instad of copy) no *i and ++i wold be anymore possible.
Now consider objects of type 4:
class A
{
int m[15000000]; //15 million integers
public:
int& operator[](unsigned x) { return m[x]; }
const int& operator[](unsigned x) const { return m[x]; }
};
Such a huge beast will be problematic to be allocated on the stack in the most of the systems. It will most likely leave on the heap, and owned / referred by (smart) pointers. Its address will be moved between its pointers, but the object itself will not be movable. It may still be copyable.
There is another subtle case: when A is itself a pointer to the dynamically allocated huge array: This is the same as std::vector: It is movable since it is itself a "smart pointer" who owns the dynamically allocated data, but may be also copyable, since there may be the case you need a new different copy of the owned data.
Now cosider type 5:
class window
{
private:
HWND handle;
public:
window() :handle(CreateWindow(....))
{ .... }
~window() { DestroyWindow(handle); }
};
Here an instance of window represents a window existing on screen. What does it mean "copy" or "move"?
This is most likely the case for mutex, condition_variable, etc., where both copy and move are disabled.
