[Surcharge d'opérateurs] Type de retour

**Nanoc** · 21/11/2008, 22h30

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

**Kurisu** · 21/11/2008, 23h14

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

maintenant, prenons l'exemple suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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é.

**Nanoc** · 22/11/2008, 01h05

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

const rational& operator++();

Avec un const. Pourquoi ?

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

**koala01** · 22/11/2008, 14h23

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