std::unique_ptr usage

问题

std::unique_ptr<int> p1(new int);
std::unique_ptr<int> p2(new int);
p2=p1;

It seems here that p1 is no longer "unique" since p2 refer to it also

It is legal c++ ? Does unique_ptr have copy_semantics ? If no, and if it has only move semantics, is p1 set to NULL after assign it to p2 ?

EDIT:

ok so the correct version is

 p2=std::move(p1)

According to that, after this assign, p1 is not valid ? And the difference with auto_ptr is here? it is more safe to explictly specfiy transfer of ownership than implicitly as it is the case with auto_ptr I guess

回答1:

std::unique_ptr is non-assignable and non-copyable. You need to use std::move();

so

p1 = std::move(p2);

Have a look here for more info.

回答2:

Here is an article I wrote which answers your questions. I originally wrote this article to present an emulation of unique_ptr. However you can ignore the first few paragraphs dealing with the emulation and just start reading at "Basic Examples".

http://howardhinnant.github.io/unique_ptr03.html

Edit:

I had trouble distilling the above linked article down to something small enough to make a practical answer in this format. However here is my best shot:

The reason: Safety in generic code. One can not really make copies of either auto_ptr or unique_ptr. Consider:

template <class T>
void foo(T t)
{
    T copy_of_t = t;  // line 4
    assert(copy_of_t == t);
}

It is not unusual at all for generic code to look like foo above. The assert is probably not actually there, but the assumption that the assert would hold often is there ... implicitly. Indeed, a popular implementation of std::sort had exactly this logic in 1996, which is exactly what prompted the second auto_ptr redesign (which helped, but didn't completely fix the problem).

回答3:

As per this, p2=p1 is a compilation error.

来源：https://stackoverflow.com/questions/5622764/stdunique-ptr-usage