Discussion :

[Nanoc]

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]

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]

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]

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

[loufoque]

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

[Nanoc]

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

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

[loufoque]

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

[white_tentacle]

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.

[Médinoc]

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

[Nanoc]

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 ?

[Profman]

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

En effet ^^