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" puisque p2 s'y réfère aussi
C'est légal c ++? Est-ce que unique_ptr a copy_semantics? Si non, et s'il n'a que des sémantiques de déplacement, p1 est-il défini sur NULL après l'avoir affecté à p2?
MODIFIER:
ok donc la bonne version est
p2=std::move(p1)
D'après cela, après cette affectation, p1 n'est pas valide? Et la différence avec auto_ptr est là? il est plus sûr de spécifier explicitement le transfert de propriété qu'implicitement comme c'est le cas avec auto_ptr je suppose
std :: unique_ptr est non assignable et non copiable. Vous devez utiliser std :: move ();
donc
p1 = std::move(p2);
Jetez un oeil 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 dans "Exemples de base".
http://howardhinnant.github.io/unique_ptr03.html
Modifier:
J'ai eu du mal à distiller l'article lié ci-dessus en 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 de copies de
auto_ptr
ouunique_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 du tout inhabituel que le code générique ressemble à
foo
ci-dessus. Leassert
n'est probablement pas réellement là, mais l'hypothèse que leassert
tiendrait souvent est là ... implicitement. En effet, une implémentation populaire destd::sort
avait exactement cette logique en 1996, et c'est exactement ce qui a incité le secondauto_ptr
refonte (ce qui a aidé, mais n'a pas complètement résolu le problème).
Selon ceci , p2=p1
est une erreur de compilation.