[Surcharge d'opérateurs] Type de retour

Bonjour tout le monde !

J'ai une question qui me dérange depuis longtemps et que de multiples essais n'ont pas réussi à solutionner.
Quel doit être le type de retour d'un opérateur surchargé ?

Prenons par exemple une classe vecteur et son opérateur +=.

Code:

---

Vecteur& Vecteur::operator+=(const Vecteur& v);

---

La référence retournée doit-elle être constante ou pas ?

De même pour les opérateurs renvoyant une valeur, doit-elle être constante ou pas ?

Code:

---

Vecteur operator+(const Vecteur& v,const Vecteur& w);

---

D'après GoTW, les retours doivent être const, d'après les exemples de la FAQ, il n'y a pas de const, et c'est comme cela pour toutes les sources; on trouve les deux avis.
Personellement, j'ai jamais mis de const, mais je ne suis pas convaincu de cette approche.

Merci à vous.

Refléchis une seconde à ce que tu veux obtenir:
l'operator+= prends une variable à ajouter qu'il n a pas à modifier (et qui peut être constante) et retourne une référence sur lui-même dont il se peut que veuilles encore modifier des choses.
Donc le chemin le plus sûr, c'est type& operator+=(const type& rhv); .
Pour l'opérateur + global, regarde du côté de Boost.operator pour voir ce qu'il te permet d'obtenir.

Exemple, un vec4(x,y,z,w):

Code:

---

1 2	vec4& vec4::operator+=(const vec4& rhv) { /* somme */ return *this; }

---

maintenant, prenons l'exemple suivant:

Code:

---

1 2 3 4 5

vec4 a(des valeurs); vec4 b(autres valeurs);   //et on veut faire l'addition et enchaîner direct sur un membre. (a += b).y = b.z;

---

cela revient à a += b; et a.y = b.z;
c'est pas recommandé, certes, mais ca se peut.

J'espère que ca t'a aidé.

Oui, c'est justement ce à quoi je pensais. Le type de retour peut être utilisé comme rvalue pour une autre opération (même si c'est pas du meilleur style). C'est pourquoi j'ai toujours mis le type de retour non-constant.

Mais si je prends par exemple cette classe de boost: http://www.boost.org/doc/libs/1_37_0/boost/rational.hpp , l'opérateur ++ a pour signature :

Code:

---

const rational& operator++();

---

Avec un const. Pourquoi ?

De même dans ce code tiré de GOTW (http://www.gotw.ca/gotw/006.htm) :

Code:

---

1 2 3 4 5 6 7 8

const Polygon operator+( const Polygon& lhs, const Polygon& rhs ) { Polygon ret = lhs; const int last = rhs.GetNumPoints(); for( int i = 0; i < last; ++i ) // concatenate ret.AddPoint( rhs.GetPoint(i) ); return ret; }

---

Je pense que les gens qui ont écrits ces codes savent ce qu'ils font et qu'il y a sûrement une raison à ces "const". Mais je ne vois pas à part empêcher justement certains trucs moches en chaînant des opérations, mais dans ce cas, pourquoi tous les opérateurs n'ont-ils pas un type de retour constant ?

Salut,

Le cas du polygone est intéressant parce qu'il s'agit d'un objet que l'on pourrait qualifier "d'atomique"...

Si tu le modifie d'une quelconque manière (en déplaçant l'un de ses angles, ou en modifiant le nombre de côtés dont il est fait), tu obtient littéralement "un autre" polygone.

Il est donc "normal" de considérer qu'un polygone doive... rester constant ;)

La seule optique qui reste "cohérente" est alors de se dire que, si tu additionne deux polygone, tu en crée un troisième qui... n'a rien à voir avec les deux autres, et qui ne pourra pas non plus être modifié.

Dans d'autres cas, il peut être "cohérent" d'estimer qu'un objet puisse être modifié, sans *forcément* obtenir un nouvel objet, et, dans ce cas, il peut être non constants ;)

Ça sert à ne pas pouvoir faire
a + b = c;

Ok. Mais pour les nombres rationnels, comment interpréter la constance du type retourné ?

Peut-on dégager une "règle" générale ?

La constance du type retourné sert à ce que ce que j'ai écrit plus haut ne compile pas, parce que sinon ça marche.

En général, il vaut mieux renvoyer un const, puisque modifier le résultat de l'opération est bizarre le plus souvent.

Il y a aussi des exceptions : operator= doit renvoyer un non const pour un smart pointer (pas possible autrement).

Une bonne pratique, c'est que l'objet a le même comportement qu'un type standard (int par exemple). C'est relativement intuitif, du coup.

Il ne faut pas oublier que sur un compilateur conforme (à savoir: autre que Visual), une fonction prenant une référence non-const en paramètre ne peut pas modifier un temporaire non-nommé, donc le (a+b)=c ne compilera pas, const ou pas const...

Citation:

---

Envoyé par loufoque

La constance du type retourné sert à ce que ce que j'ai écrit plus haut ne compile pas, parce que sinon ça marche.

---

Mouais. Mais alors pourquoi d'autres opérateurs ne renvoient pas d'objets constants ?

Citation:

---

Envoyé par loufoque

Ça sert à ne pas pouvoir faire
a + b = c;

---

En effet ^^