Discussion :

[zouip]

Si je me souviens de mes vieux cours mon prof nous avait simplement expliqué que déclarer un opérateur dans la classe obligeait à placer la seconde opérande à droite de l'instance courante, ça m'a largement suffit pour comprendre le fonctionnement et je ne suis jamais étonné du comportement d'un opérateur. Il ne faut pas être un gourou en la matière pour ne jamais faire d'erreur d'interprétation du code.
Aussi je suis un peu étonné de vous voir prêcher comme un vérité quelque chose qui n'est jamais que... très subjectif.
Par contre vous avez complètement éclipsés ma remarque sur la constance de l'opérande de gauche ce qui est tout de même un peu plus important (car ça ça change la sémantique).

Dans le cas d'une surcharge interne, ta remarque sur la constance de l'opérande de gauche est judicieuse en effet.
Pour ce qui est de la surcharge externe, il ne s'agit pas de prêcher une espèce de vérité comme tu dis, mais juste de proposer un modèle plus cohérent à l'opération +. De plus, si dans le fond, la surcharge interne ou externe ne change pas fondamentalement, en pratique, la surcharge externe des opérateurs symétriques est plus avantageuse.
En effet, avec un opérateur + externe, si un transtypage d'un des deux opérandes doit être réalisé, il peut l'être aussi bien sur l'opérande de gauche que sur l'opérande de droite.

Exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
class B {
      /* ... */    
};
 
class A {
      friend A operator+(const A&, const A&);
 
      public:
        A(const B&);  
      /* ... */      
};

On peut faire:

Code :

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

1
2
3
4
A var1;
B var2;
 
A var3 = var2 + var1; // <=> A var3 = var1 + var2;

Ce qui est moins aisé avec une surcharge interne de l'opérateur +...

[Luc Hermitte]

La "libération" des opérateurs binaires est liée au besoin de symétrie quand des conversions implicites sont possibles.
C'est tout.

[NiamorH]

Aussi je suis un peu étonné de vous voir prêcher comme un vérité quelque chose qui n'est jamais que... très subjectif.

Il existe des cas où définir les opérateurs arithmétiques en dehors de la classe est plus utile qu'à l'intérieur. L'inverse n'est pas vrai. -> Autant prendre des bonnes habitudes. En tout cas il ne s'agit pas de superstition.

[Garulfo]

Pourquoi toujours? Passer des int, float,... par références améliore les performances?

Ce n'est pas pour une raison de performances que ce serait plus intéressant, même s'il y a cet avantage en plus. C'est intéressant pour des raisons de suretés qui rejoignent le comportement qu'on obtient avec des paramètres de fonctions en mathématiques. Le fait qu'il n'y ait aucun intérêt au niveau de la performance pour int et float ne dérange en rien. Ce qui compte c'est qu'il n'y ait pas de désagréments et de problèmes cachés, ce qui est le cas.

[...]
Pour moi le const est utilisé pour associer une propriété à une donnée et non comme un moyen plus sûr, il permet une meilleur lecture du code, (d'ailleurs si je ne me trompe pas le compilateur apprécie aussi ) ... Mais ça c'est une question de point de vue je suppose

Le fait qu'il te permette une meilleure lecture du code est aussi un moyen d'améliorer la sureté et la fiabilité. Donc je réitère : selon moi il eut été bon que le comportement par défaut soit de passer une référence constante et qu'il existe un moyen de faire une copie mais en l'explicitant.

[NiamorH]

Le fait qu'il n'y ait aucun intérêt au niveau de la performance pour int et float ne dérange en rien.

Il y a meme perte de performance pour ces types.

[koala01]

Ceci dit, le fait de passer un argument sous forme de référence constante doit être mis en parallèle avec les méthodes constantes et le retour constant de méthode.

C'est l'ensemble qui nous permet de passer une sorte de contrat par lequel nous nous engageons à ne pas modifier un objet, et qui permet au compilateur de veiller à ce que nous tenions nos engagements.

Et le but premier n'est pas de signaler au lecteur que telle ou telle fonction ou variable ne va pas modifiier l'objet, mais bel et bien de permettre ce genre de contrat

Il y a, bien sûr, moyen de renoncer temporairement au contrat de constance des objets avec le const_cast, mais, de manière générale, il reste beaucoup plus prudent pour tout le monde de s'en tenir aux engagement pris

[Garulfo]

[...]
Et le but premier n'est pas de signaler au lecteur que telle ou telle fonction ou variable ne va pas modifiier l'objet, mais bel et bien de permettre ce genre de contrat [...]

C'est pour cela que je dis que c'est gage de sureté et que cela aurait du être généralisé.

Cependant dire qu'il y a un but premier et second c'est faire une interprétation de la volonté du créateur (avec un petit ‘c’, car celui avec une majuscule est encore plus inatteignable )

Je pense que les deux objectifs sont là car le contrat est visible par le lecteur qui comprend donc ce qui se passe.

[Garulfo]

Il y a meme perte de performance pour ces types.

Oui mais c'est tellement négligeable que ça n'a aucun intérêt (c'est bien ce que j'ai dit).

[NiamorH]

C'est négligeable pour toi surement, mais pour des personnes qui font de l'optimisation de code, avec une fonction qui est appellée plusieurs millions de fois c'est plus négligeable.

[Garulfo]

C'est négligeable pour toi surement, mais pour des personnes qui font de l'optimisation de code, avec une fonction qui est appellée plusieurs millions de fois c'est plus négligeable.

Cela reste négligeable même plusieurs millions de fois. Il est exceptionnel que le problème vienne du fait que tu as fait un passage par valeur d'un entier au lieu d'une référence constante; y compris en programmation de calcul intensif. Normalement les problèmes viennent d'ailleurs notamment de la conception. Le problème peut venir de millions d'appels d'une fonction récursive, mais dans ce cas le problème vient de la récursivité et non du passage d'argument. Une refactorisation s'impose. Sinon l'espace mémoire utilisé est sensiblement équivalent. Je serais curieux de voir un cas réel et non artificiel où le problème vient vraiment de là.

[NiamorH]

En fait, il ne s'agit pas de problème mais bien d'optimisation. Mais je suis d'accord, dans un plan d'optimisation, cela arriverait loin derriere bien d'autres considérations.

[Garulfo]

En fait, il ne s'agit pas de problème mais bien d'optimisation. Mais je suis d'accord, dans un plan d'optimisation, cela arriverait loin derriere bien d'autres considérations.

Bin on est d'accord alors

[corrector]

Oui mais c'est tellement négligeable que ça n'a aucun intérêt (c'est bien ce que j'ai dit).

Tu as mesuré?

[Garulfo]

Tu as mesuré?

Non. Je ne perdrais pas de temps pour ça.
Je te laisse ce plaisir si ça te tente.

[corrector]

Il est exceptionnel que le problème vienne du fait que tu as fait un passage par valeur d'un entier au lieu d'une référence constante; y compris en programmation de calcul intensif.

Tu veux dire : il est exceptionnel que le passage d'un entier par référence constante créé un problème de performance par rapport au passage par valeur?

[Garulfo]

Tu veux dire : il est exceptionnel que le passage d'un entier par référence constante créé un problème de performance par rapport au passage par valeur?

Le sens contraire... ce que j'ai d'ailleurs dit « il est exceptionnel que le problème vienne du fait que tu as fait un passage par valeur d'un entier au lieu d'une référence constante ».

Certes je n'ai pas vu tous les problèmes du monde... mais je doute très fort que quelqu'un qui ait de réels problèmes de performance (mémoire dans ce cas) puisse résoudre son problème uniquement par ce procédé. Je serais curieux qu'on me montre un tel problème réel (et non qui soit créé pour l'occasion).

[Alp]

Il a été dit je ne sais plus où que le passage par référence constante n'est pas plus bénéfique que le passage par valeur pour les types dondamentaux. L'intérêt est moindre, voir nul.

[corrector]

Pourquoi toujours? Passer des int, float,... par références améliore les performances?

Ce n'est pas pour une raison de performances que ce serait plus intéressant, même s'il y a cet avantage en plus. C'est intéressant pour des raisons de suretés qui rejoignent le comportement qu'on obtient avec des paramètres de fonctions en mathématiques. Le fait qu'il n'y ait aucun intérêt au niveau de la performance pour int et float ne dérange en rien. Ce qui compte c'est qu'il n'y ait pas de désagréments et de problèmes cachés, ce qui est le cas.

Il y a meme perte de performance pour ces types.

Oui mais c'est tellement négligeable que ça n'a aucun intérêt (c'est bien ce que j'ai dit).

C'est négligeable pour toi surement, mais pour des personnes qui font de l'optimisation de code, avec une fonction qui est appellée plusieurs millions de fois c'est plus négligeable.

Cela reste négligeable même plusieurs millions de fois. Il est exceptionnel que le problème vienne du fait que tu as fait un passage par valeur d'un entier au lieu d'une référence constante; y compris en programmation de calcul intensif. Normalement les problèmes viennent d'ailleurs notamment de la conception.

Tu veux dire : il est exceptionnel que le passage d'un entier par référence constante créé un problème de performance par rapport au passage par valeur?

Le sens contraire... ce que j'ai d'ailleurs dit « il est exceptionnel que le problème vienne du fait que tu as fait un passage par valeur d'un entier au lieu d'une référence constante ».

Pour moi, il y a clairement un qui-pro-quo entre NiamorH et Garulfo.

Ou alors entre vous tous et moi.

(Il faudrait écrire "perte par rapport à" pour m'éviter ce genre de doutes...)

[corrector]

Que ma thèse soit bien claire :

void f (int);

ne sera jamais moins efficace que

void f (const int&);

[JolyLoic]

La mienne est que je n'ai aucune idée a priori sur la performance comparée de :
void f (char, char);

Et
void f (char const &, char const &);

Mais que je ne serais pas surpris que la seconde soit légèrement plus longue.