[debutant] Utilisation de l'operateur = dans une classe

Bonjour je voudrais definir un operateur = pour ma classe plane.
Ca compile bien mais ca ne fait pas ce que je desire :

Code:

---

1 2 3 4 5 6 7

plane plane::operator = (plane p) { p.name=name; p.landingGearOn=landingGearOn; p.OnAir=OnAir; return p; }

---

C'est la definition de l'operateur dans plane.cpp

Dans le main j'ai

Code:

---

1 2 3 4 5 6

plane p= plane("abcd"); plane q(p);//c'est un copy constructor modifie : il na pas la meme valeur //pour name que p   q=p; cout <<"the (q)name is " <<q.getName()<<endl;

---

Quand j'execute le main il m'affiche :


[quote]
the (p)name is abcd
the (q)name is
p and q are not equals // c'est ici que j'ai fait q=p
the (q)name is //donc normalement on devrait avoir q name is abcd.

bien le bonjour,

une remarque, l'operateur = est sense copier la valeur de droite dans l'objet de gauche (a moins que tu ne souhaites l'utiliser dans l'autre sens, mais c'est fortement deconseille pour une question de lisibilite), hors tu fais des

Code:

---

1 2 3

p.name=name; p.landingGearOn=landingGearOn; p.OnAir=OnAir;

---

dans lesquels tu copies les attributs de this dans l'objet passe en argument

n'y a-t-il pas un soucis ?

de plus tu passes l'objet p a la methode par valeur, pas super tout ca ...

J'ajoute que tu dois renvoyer *this, donc un plane&.

Bref, va regarder un peu dans la FAQ ou sur le net pour trouver des bases sur la surcharge de l'opérateur d'affectation.

Tu n'avais pas un héritage au milieu de ces classes dans ton autre post ?
Si oui, tu NE peux PAS utiliser l'opérateur d'affectation. Voir mon autre message sur ce qui est faisable avec l'héritage.

Oui la classe plane est fille de la classe FlyingMachine. Donc si je veux utiliser l'operateur = il va falloir que je definisse cet operateur dans la classe mere FlyingMachine c'est bien ca ?


J'ai modifier ma fonction mais je sais pas quoi retoiurner ?
return this ;? //this c'est pas pour java ?

plane plane::operator = (plane p)
{
name=p.name;
landingGearOn=p.landingGearOn;
OnAir=p.OnAir;
//return p;
}

j'avoue je comprend pas pourquoi je dois retourner un object reference plane& puisque j'ai definit ma fonction comme etamt plane ...

Comme ça :

Code:

---

1 2 3 4 5 6 7 8

plane& plane::operator = (const plane& p) { name=p.name; landingGearOn=p.landingGearOn; OnAir=p.OnAir;   return *this; }

---

Le retour de l'instance courante, c'est pour ça (entre autre) :

Code:

---

1 2	plane p1, p2, p3; p1 = p2 = p3;

---

A noter qu'un tel opérateur d'affectation est inutile, celui généré par le compilo sera exactement le même.

Attention à ne pas oublie le test de l'auto-assignement :wink: :

Code:

---

1 2 3

if(this == &p) return *this;

---

Citation:

---

Attention à ne pas oublie le test de l'auto-assignement

---

Ca ne sert à rien ici, à part ajouter un test qui évitera dans 0.0001% des cas la copie de 3 données membres. Et pour les opérateurs = pour qui ça poserait problème, il y a une manière beaucoup plus propre d'écrire tout ça.

Voir la FAQ C++.

Plusieurs choses.

D'abord, si tu as de l'héritage public, redéfinir l'opérateur d'affectation va te conduire droit au mur dans un premier temps, pour finalement avoir codé une chose qui ne sert strictement à rien -- sauf à permettre à des nouveaux venus sur le projet et sur le C++ d'introduire des bugs. L'action par défaut est de l'interdire et d'embrasser entièrement une sémantique de référence, la seule immédiatement compatible avec des hiérarchies polymorphes. Si tu veux faire des copies => une fonction clone() publique qui renvoie des pointeurs, et tous les constructeurs de recopie en protégé, et tous les opérateurs d'affectation en privé non définis.
Un fois de plus, cf le bout de code que je t'avais donné précédemment -- on ne dirait pas comme ça, mais j'avais un peu anticipé les autres problèmes liés à la copie dans un contexte de hiérarchie de classes polymorphe.


Concernent le test anti-recopie à partir de soi-même, c'est effectivement non seulement une pessimisation, mais en plus cela ne résoud qu'un seul des deux problèmes liés à l'affectation de classes manipulant des ressources brutes. L'autre approche par swap résoud les deux problèmes possibles.
Bref ce test est aujourd'hui identifié comme un anti-pattern et est à bannir de tout code correct -- au profit des autres approches correctes évidemment.