std :: unique_ptr utilisation

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

Il semble ici que p1 n’est plus “unique” puisque p2 s’y réfère aussi

C’est du c ++ légal? Est-ce que unique_ptr a copy_semantics? Si non, et s’il n’a que la sémantique de déplacement, est-ce que p1 est défini sur NULL après l’affecter à p2?

MODIFIER:

ok donc la version correcte est

  p2=std::move(p1)

Selon cela, après cet atsortingbut, p1 n’est pas valide? Et la différence avec auto_ptr est ici? il est plus sûr de spécifier explicitement le transfert de propriété qu’implicitement comme c’est le cas avec auto_ptr

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

alors

 p1 = std::move(p2);

Jetez un coup d’œil ici pour plus d’informations.

Voici un article que j’ai écrit qui répond à vos questions. J’ai initialement écrit cet article pour présenter une émulation de unique_ptr. Cependant, vous pouvez ignorer les premiers paragraphes traitant de l’émulation et commencer à lire “Exemples de base”.

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

Modifier:

J’ai eu du mal à distiller l’article lié ci-dessus à quelque chose d’assez petit 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 auto_ptr ou unique_ptr . Considérer:
 template  void foo(T t) { T copy_of_t = t; // line 4 assert(copy_of_t == t); } 
Il n’est pas inhabituel que le code générique ressemble à foo ci-dessus. L’ assert n’est probablement pas vraiment là, mais l’hypothèse selon laquelle l’ assert tiendrait souvent est là, implicitement . En effet, une implémentation populaire de std::sort avait exactement cette logique en 1996, ce qui est exactement ce qui a motivé la seconde auto_ptr (ce qui a aidé, mais n’a pas complètement résolu le problème).

Par p2=p1 , p2=p1 est une erreur de compilation.