why should we use std::move semantic with unique pointers?

Question

Conceptual Question

Say we have simple example like this:

 void foo(std::unique_ptr<int> ptr)
 {
    std::cout << *ptr.get() << std::endl;
 }
 int main()
 {
    std::unique_ptr<int> uobj = std::make_unique<int>(4);
    foo(uobj );  // line-(1) Problem ,but Alternative -> foo(std::move(uobj ))
    std::unique_ptr<int> uobjAlt = uobj; // line-(2) Problem ,but Alternative -> std::unique_ptr<int> uobjAlt = std::move(uobj);        
    return EXIT_SUCCESS;
}

We know simply std::unique_ptr bound with concept of resource owning by single owner with moving resource among multiple owners while shared_ptr has opposite aspect. As example shown above, when you look at line-(1) & line-(2) you notice that some standard rules are being violated because std::unique_ptr has(deleted) no both copy constructors and copy assignable operators defined, but In order to avoid compilation errors we have to use std::move function instead.

Problem

Why modern C++ compiler cannot automatically generate instructions to move the resource among unique pointers in line-(1) and line-(2)? because we know unique pointer intentionally design for that. Why should we use std::move explicitly to instruct the machine to move ownership of the resource?

std::unique_ptr nothing but class template.we know that, But situations addressed in line-1 and line -2 having issues while compiler complain about copying unique_pointers not allowed(deleted functions).why we having these kind of errors why c++ standard and compiler vendors cannot override this concept?

Unique Pointer intentionally designed for the purpose of moving resource while passing its ownership, when we pass it as function/constructor argument or assign to another unique pointer, it conceptually should move resource with ownership nothing else, but why we should use std::move to convey compiler to actual move, why don't we have a freedom to call line-(1) and line-(2) as it is? (while intelligent compiler generate automatic move operation among unique pointers for us, unless there is const or non-const reference passing).

(Sorry for long description and broken English) Thank you.

Answer 1

unique_ptr is useful to free memory for you automatically when uobj goes out of scope. That's its job. So, since it has 1 pointer it has to free, it has to be unique, and hence its name: unique_ptr!

When you do something like this:

std::unique_ptr<int> uobjAlt = uobj;

You're issuing a copy operation, but, you're not supposed to copy the pointer, because copying means that both objects uobjAlt and uobj must both be freed, which will directly lead to a segmentation fault and a crash. So, by using std::move, you're moving ownership from one object to another.

If you want to have multiple pointers to a single object, you should consider using std::shared_ptr.

Answer 2

This has nothing to do with whether the compiler can do this. It certainly could work that way, and in fact, it did work that way prior to C++11 with std::auto_ptr<>. It was horrible.

std::auto_ptr<int> x = std::auto_ptr<int>(new int(5));
std::auto_ptr<int> y = x;
// Now, x is NULL

The problem here is that the = sign usually means "copy from x to y", but in this case what is happening is "move from x to y, invalidating x in the process". Yes, if you are a savvy programmer you would understand what is going on here and it wouldn't surprise you, at least not all of the time. However, in more common situations it would be horribly surprising:

Here's MyClass.h:

class MyClass {
private:
    std::auto_ptr<Type> my_field;
    ...
};

Here's MyClass.cpp:

void MyClass::Method() {
    SomeFunction(my_field);
    OtherFunction(my_field);
}

Here's Functions.h:

// Which overload, hmm?
void SomeFunction(Type &x);
void SomeFunction(std::auto_ptr<Type> x);

void OtherFunction(const std::auto_ptr<Type> &x);

Now you have to look at three different files before you can figure out that my_field is set to NULL. With std::unique_ptr you only have to look at one:

void MyClass::Method() {
    SomeFunction(std::move(my_field));
    OtherFunction(my_field);
}

Just looking at this one function I know that it's wrong, I don't have to figure out which overload is being used for SomeFunction, and I don't have to know what the type of my_field is. There's definitely a balance that we need to have between making things explicit and implicit. In this case, the fact that you couldn't explicitly tell the difference between moving and copying a value in C++ was such a problem that rvalue references, std::move, std::unique_ptr, etc. were added to C++ to clear things up, and they're pretty amazing.

The other reason why auto_ptr was so bad is because it interacted poorly with containers.

// This was a recipe for disaster
std::vector<std::auto_ptr<Type> > my_vector;

In general, many templates worked poorly with auto_ptr, not just containers.