J'ouvre ce débat à la suite de cette discussion dans laquelle je présentais le principe du copy-and swap sous la forme de
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 | TableauInt & operator = (TableauInt const & rhs)
{
TableauInt temp(rhs); // copie de l'élément affecté
swap(temp); //inversion des membre de this avec la copie
return *this; // renvoie une référence sur l'élément courent
// la copie est détruite en sortant de la fonction
} |
Envoyé par Médinoc
Juste une chose pour le copy-and-swap: prendre directement la source par valeur peut éviter la copie quand on utilise l'opérateur = avec un temporaire:
| Code C++ : | Sélectionner tout |
1 2 3 4 | TableauInt::TableauInt& operator=(TableauInt tmp) { swap(tmp); return *this; } |
Personnellement, j'aurais cependant tendance à préférer la copie explicite pour la simple raison (sans fondement technique) que j'ai l'impression que l'on code souvent "par habitude", et que cela aura l'avantage de garder le code cohérent par rapport aux autres fonctions manipulant des paramètres qu'elles ne doivent pas modifier.
On répète en effet inlassablement que
si une fonction ne doit pas modifier l'objet qui lui est transmis en paramètre et que l'objet est plus gros qu'un simple primitif, il y a lieu de le passer par référence (pour éviter la copie de l'objet) constante (pour éviter que la fonction ne tente de le modifier indument)
est-il préférable de laisser la copie se faire de manière implicitement, quitte à "briser" la cohérence par rapport au reste du code est-ce au codeur de la fonction de veiller à créer sa propre copie de l'objet en question y a-t-il la moindre raison technique qui pourrait justifier la préférence d'une technique par rapport à l'autre Ces questions sont, évidemment, à mettre en perspective par rapport à la discussion citée, à savoir, le fait de devoir redéfinir l'opérateur d'affectation dans le respect de la grande règle des trois (si l'on a du définir un comportement spécifique pour une des fonctions parmi le constructeur par copie, l'opérateur d'affectation ou le destructeur, il y a lieu de définir un comportement spécifique pour les trois).
Je sais parfaitement qu'il y a maintenant la possibilité d'utiliser éléments RAII pour s'éviter cette peine, mais je vous demande de ne pas faire entrer cet aspect en ligne de compte
