Envoyé par
pseudocode
Même si B hérite de A ?
Si B hérite de A, on peut, décemment, estimer que la comparaison se fera de manière identique, quitte à ce qu'il y ait redéfinition d'une des fonctions qui intervient dans le processus.
Autrement, c'est plutôt du coté d'un problème de conception qu'il faudra se tourner 
Tu veux dire que le compilateur génère une erreur si je n'ai pas explicitement overridé l'opérateur ?
Exactement:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| #include <iostream>
class MaClass
{
/* n'importe quoi */
};
int main()
{
MaClass c1;
MaClass c2;
if(c1==c2)
{
std::cout<<"c1 et c2 sont identiques"<<std::endl;
}
} |
provoque l'erreur
main.cpp|10|error: no match for 'operator==' in 'c1 == c2'|
C'est justement ma critique personnelle depuis le début. Je préfèrerai que la sémantique des opérateurs présents "de base" soit inaltérable par le programmeur.
Il en va de même pour les fonctions...
Si je nomme une fonction membre "equal" ou "less", l'utilisateur peut, décemment, s'attendre à ce qu'elles effectuent une comparaison entre deux objets.
Si elles ont un autre effet, j'en reste le seul responsable, et c'est que j'ai mal choisi le nom de ma fonction
Si je décide, pour une raison qui m'est propre, de modifier la sémantique d'un opérateur, il m'appartient de choisir effectivement de le faire (à ma charge de motiver et de documenter ma décision) ou non
Je ne vois pas pourquoi on appliquerait aux opérateurs des règles différentes de celles que l'on applique aux fonctions
Mais bon, a force on va finir par croire que je suis un anti-cplusplussien, alors que j'aime plutôt bien ce langage. Je le trouve juste trop "permissif" a mon gout pour l'utiliser dans un contexte industriel, sans prendre une liste (que je juste trop excessive) de précautions.
Ce que tu appelle permissivité, j'aurais tendance à l'appeler libre arbitre.
Tu remarqueras que c'est encore une question de point de vue 
Répondre avec citation
je vous lis pendant la pause café. J'ai sans doute mis suffisamment le souk dans vos têtes bien faites. Je suis vraisemblablement plus attaché à l'aspect business... Certains projets complètement pourris dont plus personne ne veut peuvent être des opportunités fantastiques, on arrive sur un code patché de partout , plein de rustines douteuses, de bugs irrattrapables que les users contournent quotidiennement.
A méditer: La solution la plus simple est toujours la moins compliquée
.
(enfin ceux où il faut juste pondre du code)
Partager