std :: unique_ptr usage

Question

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

Il semble ici que p1 n'est plus "unique" depuis p2 reportez-vous à elle aussi

Il est légal de c++ ? Ne unique_ptr ont copy_semantics ? Si non, et si elle n'a qu'une sémantique de déplacement, soit p1 la valeur NULL après l'attribuer à p2 ?

EDIT:

ok, donc la version correcte est

 p2=std::move(p1)

Selon que, après cette attribuer, p1 n'est pas valide ? Et la différence avec auto_ptr est ici? il est plus sûr pour explicitement specfiy transfert de propriété que de façon implicite comme c'est le cas avec auto_ptr je suppose

Answer 1

std :: unique_ptr est non assignable et non copiable. Vous devez utiliser std :: move ();

alors

 p1 = std::move(p2);
 

Regardez ici pour plus d'informations.

Answer 2

Voici un article que j'ai écrit qui répond à vos questions. Au départ, j'avais écrit cet article pour présenter une émulation de unique_ptr. Cependant, vous pouvez ignorer les premiers paragraphes traitant de l'émulation et de démarrer la lecture à "Exemples de Base".

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

Edit:

J'avais du mal à la distillation de l'article ci-dessus liés à quelque chose d'assez petite taille pour faire une réponse pratique dans ce format. Cependant voici mon meilleur coup:

La raison: la Sécurité dans le code générique. On ne peut pas vraiment faire des copies de soit auto_ptr ou unique_ptr. Considérer:

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

Il n'est pas rare pour les génériques code pour ressembler foo - dessus. L' assert est sans doute pas fait il y a, mais l'hypothèse que l' assert tiendrait souvent il y a ... implicitement. En effet, un quartier populaire de la mise en œuvre de l' std::sorta exactement cette logique, en 1996, qui est exactement ce qui a amené le deuxième auto_ptr refonte (qui a aidé, mais n'a pas complètement résoudre le problème).

Answer 3

Selon cela , p2=p1 est une erreur de compilation.