Constructeur de copie et l'opérateur = surcharge en C++: est une fonction commune possible?

Depuis un constructeur de copie

MyClass(const MyClass&);

et un opérateur = surcharge

MyClass& operator = (const MyClass&);

ont à peu près le même code, le même paramètre, et ne diffèrent que sur le retour, est-il possible d'avoir une fonction commune pour les deux à utiliser?

  • "...ont à peu près le même code..."? Hmm... Vous devez être en train de faire quelque chose de mal. Essayez de réduire la nécessité d'utiliser des fonctions définies par l'utilisateur pour le présent et laisser le compilateur faire tout le sale boulot. Cela signifie souvent l'encapsulation des ressources dans leur propre objet membre. Vous pourriez nous montrer un peu de code. Nous avons peut-être certains de la bonne conception des suggestions.
  • Double Possible de la Réduction de la duplication de code entre l'opérateur= et le constructeur de copie
InformationsquelleAutor MPelletier | 2009-11-14
  1. 114

    Oui. Il y a deux options communes. - Ce qui est généralement déconseillé - est d'appeler le operator= du constructeur de copie explicitement:

    MyClass(const MyClass& other)
{
    operator=(other);
}

    Cependant, en fournissant un bon operator= est un défi quand il s'agit de traiter avec l'ancien état et des questions découlant de l'auto attribution. Aussi, tous les membres et les bases obtenir initialisé par défaut en premier, même si elles sont cédées à partir de other. Cela peut même ne pas être valable pour tous les membres et les bases, et même si il est valide, il est sémantiquement redondante et peut être pratiquement cher.

    De plus en plus populaire, la solution est de mettre en œuvre operator= en utilisant le constructeur de copie et une méthode d'échange.

    MyClass& operator=(const MyClass& other)
{
    MyClass tmp(other);
    swap(tmp);
    return *this;
}

    ou encore:

    MyClass& operator=(MyClass other)
{
    swap(other);
    return *this;
}

    Un swap fonction est généralement simple à écrire qu'il vient de swaps de la propriété de l'intérieur et ne pas avoir à nettoyer état existant ou d'allouer de nouvelles ressources.

    Avantages de la copie et de swap idiome, c'est qu'il est automatiquement auto-attribution de sécurité et de fournir de l'échange de l'opération n'est pas remise est également fortement exception coffre-fort.

    Fortement exception coffre-fort, une "main" écrit opérateur d'affectation a généralement à attribuer une copie des nouvelles ressources avant de l'allocation du cessionnaire de la vieille ressources, de sorte que si une exception se produit l'allocation de nouvelles ressources, l'ancien état peut encore être retournés pour. Tout cela n'est gratuit à partir d'un copier-and-swap, mais est généralement plus complexe, et donc source d'erreurs, de le faire à partir de zéro.

    La seule chose à faire attention est de s'assurer que la méthode d'échange est un véritable échange, et non pas la valeur par défaut std::swap qui utilise le constructeur de copie et l'opérateur d'affectation de lui-même.

    Généralement un memberwise swap est utilisé. std::swap fonctionne et est "pas de jeter" garanti avec tous les types de base et les types pointeur. La plupart des pointeurs intelligents peuvent également être échangé avec un pas de jet de garantie.

    • En fait, ils ne sont pas des opérations courantes. Alors que la copie ctor la première fois initialise les membres de l'objet, l'opérateur d'affectation remplace les valeurs existantes. Considérant cela, alling operator= à partir de la copie ctor est en fait assez mauvais, parce qu'il initialise tout d'abord, toutes les valeurs par défaut juste de les remplacer avec les autres objets de valeurs par la suite.
    • Je l'ai dit à des options communes, pas d'opérations. Je suis complètement d'accord que le fait d'appeler operator= à partir d'un constructeur de copie n'est pas bonne, mais que vous n'avez à regarder raisonnable au sujet du monde réel code pour voir comment il est.
    • Euh, vous n'avez pas il suffit de répondre à mon explication?
    • Peut-être à "je ne recommande pas", ajouter "et aucune C++ expert". Quelqu'un pourrait venir le long et ne parviennent pas à réaliser que vous n'êtes pas simplement en exprimant des personnels de la minorité de préférence, mais la jurisprudence constante de consensus de l'opinion de ceux qui ont vraiment pensé à ce sujet. Et, OK, peut-être que je me trompe et C++ expert ne vous le recommande, mais personnellement, je serais encore fixer le gant pour quelqu'un de venir avec une référence pour cette recommandation.
    • Oui, j'ai répondu à votre commentaire. À mon humble avis, les deux options sont très fréquents, mais vous êtes en désaccord. La popularité est, dans une certaine mesure, une question d'opinion, donc je suis heureux d'être en désaccord sur ce point, mais je suis curieux de savoir pourquoi j'ai été downvoted qui devrait signifier "mal ou peu serviable", qui n'était pas mon intention.
    • Jessop: je n'aime pas le son trop prescriptives, les gens utilisent C++ heureusement (ou pas si heureusement) dans de nombreuses façons différentes. J'ai ajouté le "je ne recommande pas" après re-lecture de ma réponse, parce que je sentais que ma désapprobation n'était probablement pas montré assez fortement par le contenu du paragraphe suivant.
    • Assez juste, je upvoted vous déjà de toute façon :-). Je me dis que si quelque chose est largement considéré comme la meilleure pratique, alors il est mieux de le dire (et de le regarder à nouveau si quelqu'un dit que c'est pas vraiment le meilleur, après tout). De même, si quelqu'un a demandé "est-il possible d'utiliser les mutex en C++", je ne dirais pas "c'est assez commun option est de les ignorer complètement RAII, et d'écrire des non-exception-code de sécurité que les blocages dans la production, mais il est de plus en plus populaire pour écrire décent, code du travail" 😉
    • +1. Et je pense qu'il y a toujours de l'analyse dans le besoin. Je pense qu'il est raisonnable d'avoir un assign membre de la fonction utilisée par la copie ctor et opérateur d'affectation dans certains cas (pour les classes légères). Dans d'autres cas (à forte intensité de ressources/à l'aide de cas, poignée/corps) un copier/swap est le chemin à parcourir, bien sûr.
    • D'accord, par exemple, si vous avez juste un couple de types de base dans une classe, puis l'assignation de vos membres ne ont même pas de l'auto-affectation ou d'exception-safe questions, en tout cas jusqu'à il y a peu de point dans la transpiration sujet de la plupart de solution solide. Dès que votre constructeur new ou de faire toute sorte de l'allocation des ressources, vous commencez à avoir à réfléchir à vos options un peu plus de soin.
    • Si la classe est léger, ne copie-swap de faire du mal?
    • Oui, depuis, vous n'avez pas besoin d'un swap, et je ne vois pas ce qu'il vous achète wrt exception de sécurité. Vous voudrais juste ajouter une fonction inutile (swap fonction membre), et de créer un inutile copie (depuis swap/copie serait essentiellement la même vitesse ici, il est alors inutile dans le vrai sens du terme). Mais j'ai peut-être tort, bien sûr, je suis juste de ne pas voir le point de faire des copier-swap ensuite.
    • Bien sûr, cela dépend de ce qu'est exactement "léger" est - je voulais dire une classe qui ne fait pas de gestion dynamique de la mémoire ou de la tenue de ressources. La nécessité pour l'utilisateur défini cctor ou de la cession de la fpo dans ce cas est rare, je pense - mais il peut parfois venir.
    • Ne va pas downvote vous, mais je n'ai jamais vu un constructeur de copie mis en œuvre en termes de operator= et il semble inefficace.
    • Je peux vous assurer qu'il est malheureusement fréquent. Je ne l'ai jamais vu dans le code qui aurait autrement, m'a fait penser: "C'est vraiment propre c++, ici!', cependant.
    • En fait, le lemme de devis Herb Sutter: "Si quoi que ce soit, l'idiome est exactement à l'envers: copie de la construction devrait être mis en œuvre en termes d'assignation de copie, plutôt que l'inverse." -> gotw.ca/gotw/023.htm . Bien sûr que l'article est vieux, mais il montre qu'il n'est pas fou d'une pensée 🙂
    • Pardonnez-moi si mon manque de connaissances de la montre, mais comment, dans le swap solution, est la destruction de la cible est-elle assurée?
    • J'ai été surpris par cela, donc j'ai regardé jusqu'à l'Élément 41 Exception en C++ (ce qui gotw transformé en) et cette recommandation a disparu et il recommande de copier-and-swap à sa place. Plutôt sournoisement qu'il a chuté "le Problème n ° 4: Il est Inefficace pour l'Affectation" en même temps.
    • Le swap de l'action se déplace de l'ancien état de la cible dans la copie temporaire (comme la copie de l'état est déplacée vers la cible). Comme la première copie locale de l'opérateur d'affectation, il est hors de portée à la fin du corps de la fonction, afin de veiller à ce que l'ancien état de la cible est détruite.
    • ah que c'est bon. Je n'en attendais pas autre chose de lui, maintenant je sais qu'il fait "corriger" ça 🙂 Néanmoins, je ne pense pas que c'est en particulier le "mauvais" pour appeler une fonction commune à partir à la fois de la cctor et copie opérateur d'affectation, comme certaines personnes ici disent. Pourquoi il la façon complexe si une solution simple suffit.
    • +1 Sutter couvre également la copie de le remplacer par un plus tard gotw: gotw.ca/gotw/059.htm
    • En fait, c'est exactement comment T a(b); a été défini waaay dos: d'abord appeler le constructeur par défaut et ensuite appeler l'opérateur d'affectation. Depuis cela s'est avéré être trop inefficaces, la notion de "constructeur de copie" a été introduit en C++ 🙂
    • J'ai un souci à propos de la signature de Maclasse& operator=(MyClass autres). Le Visual C++ 2013 compilateur semble toujours générer automatiquement une Maclasse& operator=(const Maclasse& autre) en fonction de la mise en œuvre de memberwise affectation. Si le Maclasse& operator=(MyClass autres) signature ont supprimé la VS généré?
    • N'est pas la première suggestion, th enot recommandé illégal? Si l'opérateur = supprime de la mémoire, cette opération va supprimer aléatoire (non initialisée) pointeur. Je crois qu'il n'est pas simplement "non recommandé" mais d'une garantie de crash
    • la mémoire"? Ce que la mémoire? Il semble que vous avez un exemple précis en tête. Si operator= est écrit correctement, il ne devrait pas donner lieu à un accident.
    • l'opérateur = est censé supposer que l'objet existe déjà. Donc si il y a un pointeur, l'objet doit être supprimé. Constructeur de copie ne fonctionne pas. Votre deuxième solution où l'opérateur = est écrit en termes de constructeur de copie de sens. Mais la première, comment voulez-vous écrire, si l'objet contient un pointeur alloué dynamiquement?
    • Est-il une restriction d'écrire MyClass(other).swap(*this); ou this->swap(MyClass(other)); ?

    InformationsquelleAutor CB Bailey
  2. 13

    Le constructeur de copie exécute le premier temps de l'initialisation des objets utilisés pour être cru de la mémoire. L'opérateur d'affectation, otoh, que, remplace les valeurs existantes par de nouvelles. Plus souvent que jamais, cela implique de rejeter la vieille ressources (par exemple, la mémoire) et de l'allocation de nouveaux.

    Si il y a une similitude entre les deux, c'est que la cession de l'opérateur effectue la destruction et la copie de la construction. Certains développeurs ont utilisé pour la mise en œuvre de la cession en place de destruction suivie par le placement de copie de la construction. Cependant, c'est un très mauvaise idée. (Si c'est l'opérateur d'affectation d'une classe de base qui a appelé lors de l'affectation d'une classe dérivée?)

    Ce qui est généralement considéré comme la forme canonique de l'idiome de nos jours est à l'aide de swap que Charles a proposé: 

    MyClass& operator=(MyClass other)
{
    swap(other);
    return *this;
}

    Il utilise la copie de la construction (à noter que other est copié) et la destruction (il est détruit à la fin de la fonction) -- et il les utilise dans le bon ordre, trop: la construction (peut échouer) avant la destruction (qui ne doit pas échouer).

    • Devrait swap être déclaré virtual?
    • Les fonctions virtuelles sont utilisées dans polymorphes hiérarchies de classes. L'affectation des opérateurs sont utilisés pour les types de valeur. Les deux à peine mélanger.
    InformationsquelleAutor sbi
  3. -4

    Quelque chose qui me dérange à propos de:

    MyClass& operator=(const MyClass& other)
{
    MyClass tmp(other);
    swap(tmp);
    return *this;
}

    Tout d'abord, la lecture de la parole "swap" quand mon esprit est la pensée de la "copie" irrite mon bon sens. Aussi, je m'interroge sur le but de cette fantaisie truc. Oui, toutes les exceptions dans la construction de la nouvelle (copie) des ressources devrait se faire avant le swap, ce qui semble être un moyen sûr de s'assurer que toutes les nouvelles données est rempli avant de le faire vivre.

    C'est très bien. Donc, concernant les exceptions qui se produisent après l'échange? (quand la vieille ressources sont détruits lorsque l'objet temporaire est hors de portée) du point De vue de l'utilisateur de la mission, l'opération a échoué, sauf qu'il n'a pas. Il a un énorme effet de bord: la copie ne se produisent réellement. C'était seulement un nettoyage des ressources qui a échoué. L'état de l'objet de destination a été modifié, même si l'opération semble de l'extérieur de l'échec de la.

    Donc, je propose plutôt de "swap" pour faire plus naturel "transfert":

    MyClass& operator=(const MyClass& other)
{
    MyClass tmp(other);
    transfer(tmp);
    return *this;
}

    Il y a encore de la construction de l'objet temporaire, mais la prochaine action immédiate est de libérer toutes les ressources actuelles de la destination, avant de se déplacer (et Invalide donc ils ne seront pas en double-libéré) les ressources de la source.

    Au lieu de { construire, de se déplacer, détruire }, je propose { construire, détruire, déplacer }. Le mouvement, qui est le plus dangereux de l'action, qui est pris en dernier après que tout a été réglé.

    Oui, la destruction échouer est un problème dans l'un des deux systèmes. Les données sont endommagées (copiées lorsque vous ne pensiez pas que c'était) ou de perte (libéré lorsque vous ne pensiez pas que c'était). Perdu, c'est mieux que corrompu. Aucune donnée n'est mieux que de mauvaises données.

    De transfert au lieu de swap. C'est ma suggestion de toute façon.

    • Un destructeur ne doit pas échouer, de sorte que les exceptions à la destruction ne sont pas attendus. Et, je ne comprends pas quel serait l'avantage de déplacer le déplacer derrière la destruction, si un déménagement est la plus dangereuse de l'opération? I. e., dans le schéma standard, un déménagement à l'échec de ne pas corrompre l'ancien état, tandis que votre nouveau régime n'. Alors pourquoi? Aussi, First, reading the word "swap" when my mind is thinking "copy" irritates -> en tant Que bibliothèque de l'écrivain, tu sais généralement de pratiques communes (copie+swap), et la difficulté est my mind. Votre esprit est en fait caché derrière l'interface publique. C'est ce code réutilisable est tout au sujet.
    InformationsquelleAutor Matthew