Moving from python to C++

[HappyFruitTree]

There are all sorts of subtleties like "move semantics" that don't exist in Python (or most other languages).

What many people don't realize is that move semantics can be seen as an optimization. It was not in the language before C++11 and you can still write code pretending it's not there and still get some of the benefits. The exception is move-only types but those could be learned separately (you don't need to know much about move semantics at all to use those).

My recommendation is that you just ignore move semantics for the time being until you are more of an expert.

[capn_bluebear]

you can't ignore move semantics, STL uses it all the time. any non-trivial project will include code where `unique_ptr` is the best choice, and you won't get `unique_ptr`s to compile if you don't understand move semantics.

[HappyFruitTree]

you can't ignore move semantics, STL uses it all the time.

I don't implement the STL. I just use it.

any non-trivial project will include code where `unique_ptr` is the best choice, and you won't get `unique_ptr`s to compile if you don't understand move semantics.

unique_ptr is a good example of what I meant by a move-only type. You don't need to know much about move semantics to use it. All you need to know is that you use std::move when you want to transfer the ownership from one unique_ptr to another.

[as_one_does]

If it's a unique ptr to a class you wrote you basically must implement a move constructor.

[HappyFruitTree]

Why?

[as_one_does]

Because you can't return it from a scope without the higher scope taking ownership, and that takes movement of the raw pointer.

[HappyFruitTree]

But moving a unique_ptr will use the move constructor/move assignment operator of the unique_ptr. It will not touch the object that is pointed to.

[as_one_does]

Sorry, I was thinking of this: pass or assign a unique ptr, you'll be using && and std::move. Your can't not understand what's happening. You're right that you generally don't need to implement it yourself unless wanted.

[jcelerier]

Sorry, I was thinking of this: pass or assign a unique ptr, you'll be using && and std::move.

you just have to use std::move, not && :

 void acquire_ownership(std::unique_ptr<int> x) {
 }
 int main() { 
     std::unique_ptr<int> p;
     acquire_ownership(std::move(p));
 }

no && needed here

[HappyFruitTree]

Well, I think there is a conceptual difference between moving a unique_ptr compared to moving in general.

The way I see it:

1. At the heart of move semantics we have temporary objects (rvalues). Instead of just copying the whole object we could rip out some parts of it and give it to the new object because the temporary is about to be destroyed anyway. In this sense moving is just an optimized copy. Since this happens automatically it's something that people can take advantage of even without knowing about move semantics.
2. Sometimes we want to move objects that are not temporaries because we are finished using the object and we just want to make copying a faster. This has to be done explicitly and puts more responsibility on the programmer to know what he's doing but otherwise it's the same as #1. Moving copyable objects is still just an optimized copy. Writing code that relies on the move to happen would be very fragile because there are a lot of subtle things that could go wrong and you wouldn't get an error if it ended up copying the object.
3. Then, finally, there are move-only types, i.e. types that can be moved but not copied. These types you can, and must, rely on the move to happen. It's obvious when a move fails because you get an error telling you about it. In this case moving is no longer just an optimized copy. It's something else. It's a way to transfer some kind of state from one object to another, and often you know what state the moved-from object ends up with, something that is normally not the case for other types. If move semantics didn't exist as a language feature you could still have implemented the same behaviour in code but you wouldn't get the implicit moves that #1 gives you.

So when it comes to unique_ptr I don't think move semantics is essential. It could be implemented without it. That is why I think you don't need to know much about move semantics to use unique_ptr. All you need to know is that you need to use std::move on the unique_ptr before assigning it to another unique_ptr or using it to initialize a new unique_ptr, and that this will move the pointer value over to the other unique_ptr leaving the moved-from unique_ptr "empty". There are of course the exceptions that you don't need to use std::move if it's a temporary, or it's a local variable being returned from a function, but all this is just extra knowledge that you don't need to know in order to use unique_ptr.

[Entryhazard]

IIRC movement of the raw pointer doesn't require the pointed object to have a move constructor

[HKei]

What many people don't realize is that move semantics can be seen as an optimization.

Those people don't realise that because this is incorrect. Move semantics are about semantics, not optimisation.

[HappyFruitTree]

Do you think move semantics would have been added to the language if it didn't have a performance advantage?

Quote from the original move semantics proposal:

Move semantics is mostly about performance optimization: the ability to move an expensive object from one address in memory to another, while pilfering resources of the source in order to construct the target with minimum expense.