IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Opérateur d'affectation: copie implicite ou explicite

Le , par koala01

24PARTAGES

Salut,

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 
}
et à laquelle médinoc a répondu ceci
Citation Envoyé par Médinoc  Voir le message
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; 
}

Après mure réflexion, j'en viens à la conclusion que cela revient "choux vert et vert choux" du fait que la seule différence présente entre les deux possibilités vient de la copie explicite dans mon code de l'objet assigné contre la copie implicite dans le code de Médinoc.

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)

Ce principe est très bien dans le sens où il permet de gagner en performances à peu de frais en évitant la copie de l'objet passé en paramètre, mais qu'en est il si la fonction en question doit, justement, travailler sur une copie de l'objet (si tant est que l'objet soit copiable)
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

Une erreur dans cette actualité ? Signalez-le nous !