Pourquoi l'opérateur d'affectation de copie doit-il retourner une référence/constante ?

Question

En C++, le concept de retour de référence de l'opérateur d'affectation de copie n'est pas clair pour moi. Pourquoi l'opérateur de copie ne peut-il pas renvoyer une copie du nouvel objet ? De plus, si j'ai la classe A et les suivantes :

A a1(param);
A a2 = a1;
A a3;

a3 = a2; //<--- this is the problematic line

El operator= est défini comme suit :

A A::operator=(const A& a)
{
    if (this == &a)
    {
        return *this;
    }
    param = a.param;
    return *this;
}

Answer 1

Un petit éclaircissement sur la raison pour laquelle il est préférable de retourner par référence pour operator= par rapport au rendement par valeur --- comme la chaîne a = b = c fonctionnera correctement si une valeur est retournée.

Si vous renvoyez une référence, le travail effectué est minime. Les valeurs d'un objet sont copiées dans un autre objet.

Cependant, si vous retournez par valeur pour operator= vous appellerez un constructeur et un destructeur à CHAQUE fois que l'opérateur d'affectation sera appelé !

Donc, donné :

A& operator=(const A& rhs) { /* ... */ };

Ensuite,

a = b = c; // calls assignment operator above twice. Nice and simple.

Mais,

A operator=(const A& rhs) { /* ... */ };

a = b = c; // calls assignment operator twice, calls copy constructor twice, calls destructor type to delete the temporary values! Very wasteful and nothing gained!

En somme, il n'y a rien à gagner à retourner par valeur, mais beaucoup à perdre.

( Note : Il ne s'agit pas d'aborder les avantages d'avoir l'opérateur d'assignation qui renvoie une lvalue. Lisez les autres articles pour savoir pourquoi c'est préférable).

Answer 2

Strictement parlant, le résultat d'un opérateur d'affectation par copie n'a pas besoin de retourner une référence, bien que pour imiter le comportement par défaut du compilateur C++, il devrait retourner une référence non-const à l'objet auquel il est affecté (un opérateur d'affectation par copie généré implicitement retournera une référence non-const - C++03 : 12.8/10). J'ai vu pas mal de code qui retourne void à partir de surcharges d'assignation de copie, et je ne me rappelle pas quand cela a causé un problème sérieux. Retour à void empêchera les utilisateurs de "chaîner les tâches" ( a = b = c; ), et empêchera d'utiliser le résultat d'une affectation dans une expression de test, par exemple. Bien que ce genre de code soit loin d'être inconnu, je ne pense pas non plus qu'il soit particulièrement courant - surtout pour les types non primitifs (à moins que l'interface d'une classe ne prévoie ce genre de tests, comme pour les iostreams).

Je ne vous recommande pas de le faire, je vous signale simplement que c'est autorisé et que cela ne semble pas causer beaucoup de problèmes.

Ces autres questions de l'OS sont liées (probablement pas tout à fait des doublons) et contiennent des informations/opinions qui pourraient vous intéresser.

• Quelqu'un a-t-il éprouvé le besoin de déclarer le paramètre de retour d'un opérateur d'affectation de copie const ?
• Surcharge de l'opérateur d'affectation en C++

Answer 3

Parce que la sémantique du C - et donc du C++ - exige que la valeur de l'opérateur d'assignation soit une valeur Valeur l pour permettre (entre autres) :

a = b = 0;

Les références ont cette propriété, les valeurs r ne l'ont pas.

Answer 4

C'est en partie parce que renvoyer une référence à self est plus rapide que de renvoyer par valeur, mais en plus, c'est pour permettre la sémantique originale qui existe dans les types primitifs.

Answer 5

operator= peut être défini pour retourner ce que vous voulez. Vous devez être plus précis quant à la nature du problème ; je soupçonne que le constructeur de copie utilise operator= en interne et cela provoque un débordement de pile, car le constructeur de la copie appelle operator= qui doit utiliser le constructeur de copie pour retourner A par valeur à l'infini.