In simpler terms

1. You must implement a move constructor or a move assignment operator in order for std::move to do anything

2. The moved object could be left in an unusable state, depending on your implementation, after stealing its internal resources.

▲

bitbasher 5 hours ago | parent | next [-]

I never understood move semantics until I learned Rust. Everything is move by default and the compiler makes sure you never leave things in an unusable state.

This was a difficult mental hurdle to get over with Rust, but once you do, move semantics make a lot more sense.

edit: When I said everything is move by default, I mean everything that isn't "Copy", such as integers, floats, etc.

▲

Conscat 4 hours ago | parent [-]

What Rust loses with that decision is the ability to program the "semantics" in move semantics. Rust has no distinction between hypothetical place constructor and value constructor.

	▲	anematode 3 hours ago \| parent [-]
		A loss of functionality, but arguably a good thing, e.g. moving will never throw an exception/panic so you don't need an equivalent to is_nothrow_move_constructible

▲

grogers 4 hours ago | parent | prev | next [-]

> You must implement a move constructor or a move assignment operator in order for std::move to do anything

Bit of a nitpick, but there are sometimes other functions with overloads for rvalue references to move the contents out - think something like std::optional's `value() &&`. And you don't necessarily need to implement those move constructor/assignment functions yourself, typically the compiler generated functions are what you want (i.e. the rule of 5 or 0)

▲

jjmarr 3 hours ago | parent | prev [-]

> The moved object could be left in an unusable state, depending on your implementation, after stealing its internal resources.

The "proper" semantics are that it leaves the object in a valid but unspecified state. So, invariants still hold, you can call functions on it, or assign to it.

▲

masklinn 2 hours ago | parent [-]

> you can call functions on it

Only functions with no preconditions, unless the type makes more guarantees as to the moved-from state.

	▲	jjmarr 27 minutes ago \| parent [-]
		The guarantees is that a moved-from state is in an otherwise valid state. So, you can do things like check if a moved from std::vector is empty (often the case in practice), then start appending elements to it.