std::auto_ptr à std::unique_ptr

Avec la nouvelle norme à venir (et les pièces déjà disponibles dans certains compilateurs), le nouveau type std::unique_ptr est censé être un remplacement pour std::auto_ptr.

Ne leur utilisation exactement chevauchement (afin que je puisse faire une recherche/remplacement global sur mon code (pas que je le ferai, mais si je l'ai fait)) ou dois-je être au courant de certaines des différences qui ne sont pas apparents à la lecture de la documentation?

Aussi si c'est un remplacement direct, pourquoi lui donner un nouveau nom, plutôt que de simplement d'améliorer la std::auto_ptr?

InformationsquelleAutor Martin York | 2010-08-10
  1. 210

    Vous ne pouvez pas faire une recherche/remplacement global parce que vous pouvez copier un auto_ptr (avec des conséquences connues), mais un unique_ptr ne peut être déplacé. Tout ce qui ressemble de

    std::auto_ptr<int> p(new int);
std::auto_ptr<int> p2 = p;

    devra être au moins comme ça

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

    Comme pour les autres différences, unique_ptr peut gérer des tableaux correctement (il va appeler delete[], tandis que auto_ptr essaie d'appeler delete.

    • d'autre part, cette opération de recherche/remplacement uniquement suite à des erreurs de compilation, il ne sera pas en silence le code de saut aussi loin que je peux voir. Donc, il est sûr de le faire, si vous corriger manuellement les erreurs de compilation par la suite
    • En effet, je ne peux pas penser à un contre-exemple qui serait bien défini avec auto_ptrs et UB avec unique_ptrs.
    • il semble donc que unique_ptr est une amélioration de la auto_ptr: soutien array & supprimer toute ambiguïté
    InformationsquelleAutor Cubbi
  2. 87

    std::auto_ptr et std::unique_ptr sont incompatibles dans someways et une baisse de remplacement dans d'autres. Donc, pas de fonction rechercher/remplacer n'est pas assez bon. Cependant, après un rechercher/remplacer de travail à travers les erreurs de compilation doit tout régler à l'exception étrange cas du coin. La plupart des erreurs de compilation nécessitent l'ajout d'un std::move.

    • Portée de la fonction de la variable:

      100% compatible, tant que vous ne passez pas par valeur à une autre fonction.
    • Type de retour:

      pas 100% compatible, mais 99% compatible ne semble pas mal.
    • Fonction de paramètre par valeur:

      100% compatible avec une mise en garde, unique_ptrs doit être passé à travers un std::move appel. C'est simple comme le compilateur va se plaindre si vous n'avez pas l'obtenir.
    • Fonction de paramètre par référence:

      100% compatible.
    • Variable de membre de classe:

      Celui-ci est difficile. std::auto_ptrs sémantique de copie sont le mal. Si la classe n'autorise pas la copie puis std::unique_ptr est une baisse de remplacement. Toutefois, si vous avez essayé de donner à la classe raisonnable sémantique de copie, vous aurez besoin de changer la std::auto_ptr le code de traitement. C'est simple comme le compilateur va se plaindre si vous n'avez pas l'obtenir. Si vous avez autorisé la copie d'une classe avec un std::auto_ptr membre sans aucun code particulier, alors honte à vous et bonne chance.

    En résumé, std::unique_ptr est ininterrompue std::auto_ptr. Il interdit au moment de la compilation des comportements qui ont été souvent erreurs lors de l'utilisation d'un std::auto_ptr. Donc, si vous avez utilisé std::auto_ptr avec les soins dont il a besoin, le passage à std::unique_ptr devrait être simple. Si vous comptiez sur std::auto_ptr's un comportement étrange, alors vous avez besoin de restructurer le code de toute façon.

    • +1 pour le "vous avez besoin de restructurer le code de toute façon". auto_ptrs sont seulement bon pour ce 20.4.5/3 dit qu'ils sont bons pour.
    • Permettez-moi d'ajouter à ce que vous devriez, par tous les moyens, remplacer auto_ptr par unique_ptr dans votre code et corriger les erreurs de compilation. Vous seriez surpris de voir comment de nombreux bugs, cela permettra de les découvrir.
    InformationsquelleAutor deft_code
  3. 33

    Autant que je sache, unique_ptr n'est pas un remplacement direct. Le principal défaut qu'il fixe est l'implicite de transfert de propriété.

    std::auto_ptr<int> a(new int(10)), b;
b = a; //implicitly transfers ownership

std::unique_ptr<int> a(new int(10)), b;
b = std::move(a); //ownership must be transferred explicitly

    D'autre part, unique_ptr aura complètement nouvelles capacités: ils peuvent être stockés dans des conteneurs.

    • Scott Meyers a également mentionné dans son "Effective C++" (3e Édition) Article 13 (page 64) que les conteneurs STL exiger que leur contenu de l'exposition "normale" de la copie de comportement, afin de conteneurs de auto_ptr ne sont pas autorisés.
    InformationsquelleAutor UncleBens
  4. 27

    Herb Sutter a une belle explication sur GotW #89:

    Quel est le problème avec auto_ptr? auto_ptr est le plus charitablement caractérisé comme une courageuse tentative pour créer un unique_ptr avant le C++
    a la sémantique de déplacement. auto_ptr est maintenant obsolète, et ne doit pas être utilisé
    dans le nouveau code.

    Si vous avez auto_ptr dans une même base de code, lorsque vous obtenez une chance
    essayez de faire une recherche globale et remplacement de auto_ptr à unique_ptr; la
    grande majorité des utilisations seront les mêmes, et que cela pourrait les exposer (comme un
    erreur de compilation) ou fixe (silencieusement) un bug ou deux, vous ne savez pas que vous
    avait.

    En d'autres termes, si un mondial de la recherche et de remplacement peut "casser" votre code temporairement, vous devriez faire de toute façon: Il peut prendre un certain temps pour corriger les erreurs de compilation, mais vous permettra d'économiser que vous beaucoup plus de mal dans le long terme.

    • Grand lien. Merci beaucoup!
    InformationsquelleAutor ValarDohaeris