Использование std:: unique_ptr

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

Кажется, что p1 больше не является "уникальным", так как p2 ссылается на него также

Это законный С++? Имеет ли unique_ptr copy_semantics? Если нет, и если он имеет только перемещение семантики, то p1 устанавливается в NULL после присвоения ему p2?

EDIT:

ok, поэтому правильная версия

 p2=std::move(p1)

В соответствии с этим, после этого присваивания, p1 недействителен? И разница с auto_ptr здесь? более безопасно явно указывать передачу собственности, чем неявно, как это имеет место с auto_ptr. Думаю,

Ответ 1

std:: unique_ptr не поддается назначению и не копируется. Вам нужно использовать std:: move();

так

p1 = std::move(p2);

Посмотрите здесь для получения дополнительной информации.

Ответ 2

Вот статья, которую я написал, которая отвечает на ваши вопросы. Я изначально написал эту статью, чтобы представить эмуляцию unique_ptr. Однако вы можете игнорировать первые несколько параграфов, посвященных эмуляции, и просто начать читать в "Основные примеры".

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

Edit:

У меня возникли проблемы с переделкой вышеуказанной связанной статьи на что-то достаточно маленькое, чтобы сделать практический ответ в этом формате. Однако вот мой лучший снимок:

Причина: безопасность в общем коде. Нельзя делать копии либо auto_ptr или unique_ptr. Рассмотрим:
template <class T>
void foo(T t)
{
    T copy_of_t = t;  // line 4
    assert(copy_of_t == t);
}
Это не является чем-то необычным для родовых кода, чтобы выглядеть как foo выше. assert, вероятно, не на самом деле там, но предположение о том, что assert будет часто встречаться... неявно. Действительно, популярная реализация std::sort имела именно эта логика в 1996 году, которая именно то, что вызвало второе auto_ptr редизайн (что помогло, но не полностью устранили проблему).

Ответ 3

В соответствии с this, p2=p1 является ошибкой компиляции.