Surcharge de l'opérateur=

Bonjour si j'ai un objet X et que je veux surcharger l'operateur = lors de l'assignement à un pointeur de cet objet comme dois-je m'y prendre. Voici ce que j'ai, cependant le code ne passe jamais par là.

Code:

---

1 2 3 4 5 6

const X* const X::operator=(const X* rhs) { //Traîtement quelquonque ... rhs = this; return this; }

---

Merci!

Il n'est pas possible de surcharger les opérateurs sur autre chose que des types définis par l'utilisateur. Et les pointeurs n'en sont pas.

Tu peux arriver plus ou moins au même effet en définissant un type qui supporte operator->, mais le type de sera pas appelé foo*.

Jean-Marc, merci pour la réponse.

-------------------------------------------------
----------------- modération --------------------
-------------------------------------------------

Cette méthode fonctionne très bien pour les cas qui ne sont pas des pointeurs.

1) assigner un pointeur vers un objet à un objet de même type n'a pas de sens. Déréference plutôt ton pointeur.
2) retourner un pointeur constant vers un objet constant lors d'une assignation n'a pas de sens non plus, et casse le chaînage.
3) l'implémentation, rhs = this, ça ne fait absolument rien.

Ça dépend des situations

1)Ça a du sens ça revient à faire Object1->X = Object2->X.

2)J'admet mais cela ne sera pas utilisé pour assigner en chaîne et j'ai mis const lors d'un test en espérant que c'était la raison laquelle ça ne fonctionnait pas.

3)Si tu remarque dans mon exemple de code j'ai mis //Traîtement quelquonque parce-que la vrai implémentation était peu révélatrice au message. Si tu y tiens j'ai besoin de faire rhs = this->GetNextPoint();

De toute façon, mon point était surtout que des post désagréable et inutile n'aide personne.

Citation:

---

1)Ça a du sens ça revient à faire Object1->X = Object2->X.

---

Cela ne revient pas du tout à ça.
Ton code cherche à faire *Object1->X = Object2->X si ObjectN->X est un pointeur et Object1->X = &Object2->X si ObjectN->X est un objet.

Citation:

---

2)J'admet mais cela ne sera pas utilisé pour assigner en chaîne et j'ai mis const lors d'un test en espérant que c'était la raison laquelle ça ne fonctionnait pas.

---

Techniquement, tu peux retourner ce que tu veux, void par exemple.

Citation:

---

3)Si tu remarque dans mon exemple de code j'ai mis //Traîtement quelquonque parce-que la vrai implémentation était peu révélatrice au message. Si tu y tiens j'ai besoin de faire rhs = this->GetNextPoint();

---

Ce qui ne fait toujours rien. rhs est une variable locale, tu ne modifies pas du tout l'argument passé à ta fonction (et si tu le faisais, ce serait encore une erreur sémantique).

Citation:

---

De toute façon, mon point était surtout que des post désagréable et inutile n'aide personne.

---

Mon message avait pour but de t'indiquer que ton code c'était n'importe quoi, ce qui est effectivemment le cas.
À partir de ce commentaire tu aurais dû remettre en question tes trucs et te documenter.

Généralement, un opérateur d'affectation redéfini utilise le passage de paramètre par référence, et si c'est sensible, se protège de l'auto-affectation:

Code:

---

1 2 3 4 5 6 7 8 9

X & X::operator=(X const & src) { if(this != &src) { //Traitement de l'affectation //... } return *this; }

---

Citation:

---

Envoyé par Médinoc

Généralement, un opérateur d'affectation redéfini utilise le passage de paramètre par référence, et si c'est sensible, se protège de l'auto-affectation

---

Se protéger de l'auto-affectation est généralement une optimisation. Le code qui en a besoin pour fonctionner risque souvent des problèmes si des exceptions sont jetées pendant son exécution.

Je dirais plutôt que ce contre-idiome (*) est une pessimisation. Vu que les auto-affectations sont on ne peut plus rares. Même pas assez suffisament fréquentes pour que le test amortisse le temps qu'il a perdu dans toutes les situations nominales.

(*) car comme le dit Jean-Marc, cela ne suffit pas à avoir du code exception-safe ; alors que le code exception-safe protège toujours contre les auto-affectations.