Discussion :

[méphistopheles]

Bonjour.

J'ai créé une classe B qui hérite d'une classe A. Or A, à déjà une fonction avec l'opérateur == (définie pour une classe A).
J'ai surchergé cet opérateur dans la classe B avec un operator==(B &).
ma question porte donc sur le renvoi de A==B(A) et B(A)==B.

concrètement:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
class A {
public:
   int varA;
 
   A(arguments &args);
   A(A &a);
 
   bool operator==( const A &a)const;
}
class B : public A {
public:
   int varB;
 
   B( const int &varb, arguments & args):A(args),varB(varb){}  
   B( const int &varb, A & a):A(a),varB(varb){}
   B(B & b);
 
   bool operator==(const B &b)const
   {
       return (varB=b.varB && A::operator==(B));
   }
}

la question est: que se passe-t'il lors du code suivant:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
A an_A;
B an_B;
int I;//I quelquonque
 
bool reponse;
reponse=(an_A==A(an_A)); //renvoie true
reponse=(an_B==B(an_B)); //renvoie true
reponse=(an_A==B(an_A,I)); //renvoie ?
reponse=(B(an_A,I)==an_A); //renvoie ?
reponse=(an_B==A(an_B)); //renvoie ?
reponse=(A(an_B)==an_B); //renvoie ?

Merci de vos réponses

[Luc Hermitte]

Dans la théorie bridée-OO, tu peux passer beaucoup de temps à essayer de résoudre ce genre de question. En Java, ils en sont arrivés à 2 écoles.

En pratique, tu fais du C++ qui te permet de définir proprement des classes à sémantique de valeur, ainsi qu'une généricité fortement typée (pas d'héritage depuis un type racine unique à la void*). Ce genre de question ne se pose pas en C++ : la sémantique de valeur (en particulier l'égalité dans le cas qui nous intéresse ici) est incompatible avec les hiérarchies polymorphes (dans les 10 premières approximations)

Comprendre: l'expérience nous apprend que l'on n'a jamais besoin de connaitre la réponse à cette question, et qu'à chercher on va finir par tourner en rond.


Sinon, peut-on dire que cela se résume à résoudre un problème de dispatch multiple ? Double pour être plus exact?

[koala01]

<snip>

Code :

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

1
2
3
4
5
6
7
8
9
 
/* <sniped code> */
class B : public A {
public:
   int varB;
 
   B( const int &varb, arguments & args):A(args),varB(varb){}  
   B( const int &varb, A & a):A(a),varB(varb){}
/* more code */

Quand je vois ces quelque lignes, je ne peux m'empêcher de crier "à l'infamie"... (bon, je peux peut-être ne pas aller jusque là, je te l'accorde )

Il ne sert en effet à rien de transmettre un type primitif sous la forme d'une référence si tu n'envisage pas de l'utiliser comme un argument "in-out" (comprend: dont la valeur modifiée au sein de la fonction sera répercutée sur la valeur dans la fonction appelante).

Le fait de passer un type abstrait de donnée ("POD" ou "TAD") par référence a pour but d'en éviter la copie, qui peut être interdite (des type "non copiables"), ou qui peut réclamer énormément de ressources inutiles (un tableau alloué dynamiquement de 10.000 éléments) ou de temps de copie (TAD pour lequel la copie "membre à membre" n'est pas applicable).

La copie de type primitifs (entiers, réels, booléens et pointeurs) ne pose a priori aucun problème de ce point de vue, les ressources nécessaires à la copie d'un type primitif étant... minimes et connues à l'avance.

Les pointeurs peuvent justifier d'être passés par référence si l'idée est que le pointeur sera modifié dans la fonction appelée, pour éviter le recours aux... pointeurs de pointeurs.

Typiquement, nous déclarerons un argument sous la forme d'une référence constante dans deux cas bien précis (bien que le deuxième soit - me semble-t-il destiné à être retiré de la prochaine norme):

1. si la variable de la fonction appelante qui sert d'argument ne doit ou ne peut pas être modifiée dans la fonction appelée
2. si l'on envisage de pouvoir passer une variable temporaire, dont, fatalement (du fait de la destruction de la variable temporaire au moment où la fonction appelée sera quittée) les modifications seront perdues... une fois que l'on reprend l'exécution de la fonction appelante

[méphistopheles]

Dans la théorie bridée-OO, tu peux passer beaucoup de temps à essayer de résoudre ce genre de question. En Java, ils en sont arrivés à 2 écoles.

En pratique, tu fais du C++ qui te permet de définir proprement des classes à sémantique de valeur, ainsi qu'une généricité fortement typée (pas d'héritage depuis un type racine unique à la void*). Ce genre de question ne se pose pas en C++ : la sémantique de valeur (en particulier l'égalité dans le cas qui nous intéresse ici) est incompatible avec les hiérarchies polymorphes (dans les 10 premières approximations)

Comprendre: l'expérience nous apprend que l'on n'a jamais besoin de connaitre la réponse à cette question, et qu'à chercher on va finir par tourner en rond.


Sinon, peut-on dire que cela se résume à résoudre un problème de dispatch multiple ? Double pour être plus exact?

Aie, beaucoup de termes techniques pour moi.... en réalité, il me semblais que l'incompatibilité n'existait que dans un sens (classe mere =>classe fille) et étais automatique dans l'autre, aussi me semblais-t'il que je n'avais besoin que d'un opérateur supplémentaire dans la classe fille.... pour moi, le problème se pose car la classe A est en réalité "inconnue " (template)...

sinon, qu'est-ce qu'un dispatch ?


à koala01: oui, j'avoue que dans le cas d'un int l'économie est minime voire négative. par contre, il me semble que ce genre de prise de paramètre est rentable, à partir d'un int en entree un int en sortie (mieux vaut deux pointeurs en entrée et une sortie void, on évite ainsi la création d'une varaible locale)... enfin je suis pas sûr, mais vu qu'un pointeur a la taille d'un int...

[HanLee]

Le fait de passer un type abstrait de donnée ("POD" ou "TAD") par référence a pour but d'en éviter la copie, qui peut être interdite (des type "non copiables"), ou qui peut réclamer énormément de ressources inutiles (un tableau alloué dynamiquement de 10.000 éléments) ou de temps de copie (TAD pour lequel la copie "membre à membre" n'est pas applicable).

Remarque de terminologie : POD c'est Plain Old Data, et ça n'a rien avoir avec un TAD - type abstrait de données.

[koala01]

à koala01: oui, j'avoue que dans le cas d'un int l'économie est minime voire négative. par contre, il me semble que ce genre de prise de paramètre est rentable, à partir d'un int en entree un int en sortie (mieux vaut deux pointeurs en entrée et une sortie void, on évite ainsi la création d'une varaible locale)... enfin je suis pas sûr, mais vu qu'un pointeur a la taille d'un int...

Il est des situations où le retour de fonction est indisponible pour le retour de l'entier - par exemple parce que la fonction peut renvoyer un booléen représentant la réussite global de ce que la fonction est sensée faire - ou parce qu'il y a des contraintes au niveau du prototype de la fonction.

Il est donc pafrois nécessaire d'utiliser un type primitif sous la forme d'un parametre "in-out"...

Dans ce cas, l'utilisation d'une référence (non constante) sera largement préférable à celle d'un pointeur, parce que l'utilisation de pointeurs doit être évitée "autant que possible".

En C++ (il en va différemment en C, car le C ne connait pas les références), il est possible d'utiliser des pointeurs dans bien des cas, mais il est conseillé de ne le faire que quand... il faut les utiliser (que l'on n'a pas d'autre solution)

Je n'ai personnellement aucun problème avec les pointeurs.

Mais il est vrai que quand leur utilisation a uniquement pour but de permettre de répercuter une modification effectuée au sein d'une fonction appelée dans la fonction appelante, cela implique que l'utilisateur doit penser à "prendre l'adresse de la variable" d'un coté et qu'il faut penser à modifier "ce qui est pointé de l'autre".

L'utilisation d'une référence dans ce cadre permet décrire dans la fonction appelée un code strictement identique à celui que nous aurions écrit dans la fonction appelante.

[méphistopheles]

L'utilisation d'une référence dans ce cadre permet décrire dans la fonction appelée un code strictement identique à celui que nous aurions écrit dans la fonction appelante.

He bien, c'est pour cela que j'utilise beaucoup les référence. Mon discurs sur les pointeurs étais lié au fait qu'il me semblais qu'utiliser les références revenait à utiliser , en C, des pointeurs (mais gérés par le compilo). Je me suis peut être fourvoyé.

Concernant les opérateurs polymorphique, sinon, personne ne peut m'éclairer ?

Le résultat que je souaite obtenir est d'avoir vrai dans toutes les comparaisons citées dans le premier message, et ce sachant que je ne peut modifier la classe A...



merci

[Alp]

Pourquoi _dois-tu_ faire en sorte que tous ces tests soient vrais ?

Parce que comparer des objets de types différents en faisant en sortie qu'ils puissent être égaux, c'est très farfelu voir erronné

[Luc Hermitte]

Je maintiens que tu me sembles chercher à résoudre un problème que tu ne dois pas avoir.

Il n'existe pas de solution parfaite au problèmes de la définition du is-equals dans les hierarphies polymorphes. Fais une recherche sur le sujet, tu devrais tomber sur les deux écoles dans le contexte de Java.

Pour ce qui est de la copie et de la comparaison, dès que tu as une hiérarchie, syntaxiquement parlant tu es foutu. Quelle que soit la solution technique, il y a aura toujours un problème. Chose que tu es être en train de découvrir.
Mais heureusement, ce n'est pas grave.

Dès que tu as une hiérarchie, tu as alors des entités. Deux objets sont toujours différents, l'égalité des états n'est jamais pertinente ; peu importe que Robert et Michel soient des jumeaux, ils restent des personnes différetes. On peut se poser le problème théorique, mais en pratique, cela ne sert à rien. Au mieux on compare des propriétés que partagent toutes les entités.


Si tu nous disais plutôt quel est le vrai problème que tu cherches à résoudre?

[méphistopheles]

Oui, c'est effectivement ça mais.... houlà, c'est une longue histoire...

commençons donc par le commencement:

Il étais une fois, sur dvp, un C++ien débutant taré qui voulais faire une classe aux propriétés particulièrement tordues

et cela commença ici.
A la fin, je trouvais, me semblais-t'il la solution: une sous classe template
je rencontrais divers problèmes et les résolvais un à un jusqu'à arriver à celui-ci: L'utilisateur, puisqu'il met en entrée la classe mère, pourrais tres bien être avisé de comparer en sortie une classe mère et une classe fille d'où la question ci dessus .

Bon, voilà pour l'histoire, bonne lecture et bravo d'avance si vous résistez à l'envie de me taper la tête contre les murs

[Luc Hermitte]

Ha! Un autre problème dont j'avais gardé le souvenir que tu cherchais à inutilement trop blinder, et que les proxy suffisaient amplement.

Mais ... quel rapport avec l'égalité ?

[loufoque]

L'égalité est en effet un cas où typiquement on veut du multiple dispatch.

[Jean-Marc.Bourguet]

Le multidispatch n'est souvent pas necessaire, dans la matrice des resultats, tout ce qui n'est pas sur la diagonale est faux. Donc une structure comme:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
class B {
public:
   bool operator==(B const& other) {
      return (typeid(*this) == typeid(other)) && equalHelper(other);
   }
protected:
   virtual bool equalHelper(B const& other) {
      // verifie l'equalite de l'etat observable
   }
};
 
class D: public B {
protected:
   bool equalHelper(B const& otherBase) {
      D const& other = dynamic_cast<D const&>(otherBase);
      // verifie l'etat propre a D et retourne false
      return B::equalHelper(otherBase);
   }
};
 
class L: public D {
protected:
   bool equalHelper(B const& otherBase) {
      L const& other = dynamic_cast<L const&>(otherBase);
      // verifie l'etat propre a L et retourne false
      return L::equalHelper(otherBase);
   }
};

devrait suffire.

Mais j'ai toujours un probleme de conception, parce qu'a nouveau l'idee d'egalite implique pour moi la notion de valeur et celle de polymorphisme d'inclusion implique la notion d'entite.

[HanLee]

Le multidispatch n'est souvent pas necessaire, dans la matrice des resultats, tout ce qui n'est pas sur la diagonale est faux. Donc une structure comme:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
class B {
public:
   bool operator==(B const& other) {
      return (typeid(*this) == typeid(other)) && equalHelper(other);
   }
protected:
   virtual bool equalHelper(B const& other) {
      // verifie l'equalite de l'etat observable
   }
};
 
class D: public B {
protected:
   bool equalHelper(B const& otherBase) {
      D const& other = dynamic_cast<D const&>(otherBase);
      // verifie l'etat propre a D et retourne false
      return B::equalHelper(otherBase);
   }
};
 
class L: public D {
protected:
   bool equalHelper(B const& otherBase) {
      L const& other = dynamic_cast<L const&>(otherBase);
      // verifie l'etat propre a L et retourne false
      return L::equalHelper(otherBase);
   }
};

devrait suffire.

Mais j'ai toujours un probleme de conception, parce qu'a nouveau l'idee d'egalite implique pour moi la notion de valeur et celle de polymorphisme d'inclusion implique la notion d'entite.

Oui mais quand tu fais un type arborescent récursif style un arbre, ou un type somme ou variant, le polymorphisme d'inclusion est la solution utilisée par la plupart des gens.

[Luc Hermitte]

L'égalité sur les arbres ? Boaf.
Type somme, cela a un état ?
Pour les variants, j'utiliserai ce que les frameworks que j'utilise proposent.

[HanLee]

L'égalité sur les arbres ? Boaf.
Type somme, cela a un état ?
Pour les variants, j'utiliserai ce que les frameworks que j'utilise proposent.

Type somme = type variant ~ union

Ben, une expression arborescente par exemple, comme typiquement en OCaml on en manipule à gogo.
Et tu les représentes à l'aide d'un type somme-variant récursif.

exemple : http://pauillac.inria.fr/~levy/x/ann...ml/node25.html

[Jean-Marc.Bourguet]

Oui mais quand tu fais un type arborescent récursif style un arbre,

Mes arbres -- et plus generalement mes graphes -- ont une notion d'identite forte. J'ai deja cherche a trouver une mise en correspondance (et meme partielle), mais mettre un operateur d'egalite entre, non.

un type somme ou variant, le polymorphisme d'inclusion est la solution utilisée par la plupart des gens.

Quand j'ai un type somme l'interface n'est pas adaptee au polymorphisme d'inclusion*, elle est celle d'une valeur. Oui, je peux utiliser l'heritage dans l'implementation en C++ -- et donc une structure proche de ce que j'ai montre ci-dessus justement --, mais il s'agit d'implementation, je pourrais aussi passer a une structure d'implementation ou j'utilise un tag explicite, aucun heritage et des new avec placement pour arriver au meme effet.

Il y a derriere ceci un point important pour moi auquel il me semble avoir deja fait allusion: j'ai une idee de conception abstraite, qui va respecter des choses comme le LSP, ensuite je l'implemente. Meme si certaines techniques sont quasiment exclusivement utilisee pour implementer certaines structures abstraites (au point que j'examine particiulierement la question de la pertinence du choix quand je les utilise pour autre chose), je ne m'interdis pas de les utiliser pour autre chose.

(*) Oui, il y a une ressemblance superficielle entre les types sommes et le polymorphisme d'inclusion. Mais cette ressemblance ne doit pas faire oublier que les types sommes sont une forme de polymorphisme ad hoc et pas universel puisqu'ils sont fermes.

[Jean-Marc.Bourguet]

En passant, les types sommes sont les duals de l'heritage. L'un est ferme sur les operations, l'autre sur les types couverts. Essayer de ne pas avoir cette dichotomie (par exemple, la structure utilisee par le pattern visiteur permet d'ouvir l'espace des operateurs, au prix de la fermeture sur les types) est a ma connaissance toujours un probleme ouvert. (Chercher "expression problem" sur un moteur de recherche oriente langage de programmation comme http://www.cdiggins.com/search pour plus d'info -- il faudrait que je le refasse d'ailleurs pour voir s'il y a du neuf depuis que j'ai regarde la derniere fois).

[Médinoc]

Pour mes hérarchies, je n'utilise plus d'égalité directe.
Je ne teste l'égalité que selon des "clés" explicites des différents éléments, et il devient ainsi facile d'inclure le type de l'objet dans ladite clé.

[HanLee]

Quand j'ai un type somme l'interface n'est pas adaptee au polymorphisme d'inclusion*, elle est celle d'une valeur. Oui, je peux utiliser l'heritage dans l'implementation en C++ -- et donc une structure proche de ce que j'ai montre ci-dessus justement --, mais il s'agit d'implementation, je pourrais aussi passer a une structure d'implementation ou j'utilise un tag explicite, aucun heritage et des new avec placement pour arriver au meme effet.

Oui perso, j'utilise boost::variant<>. Mais c'est quand même lourd à l'utilisation en C++.
Une implémentation avec polymorphisme d'inclusion ne me satisfait pas du tout, à cause de la gestion de la mémoire.

Mes arbres -- et plus generalement mes graphes -- ont une notion d'identite forte. J'ai deja cherche a trouver une mise en correspondance (et meme partielle), mais mettre un operateur d'egalite entre, non.

Mais, supposons qu'on manipule des expressions arborescentes.
Je réalise un optimiseur (si je fais un compilateur), ou bien je fais des transformations en calcul formel (substitution d'une expression par une autre).

Pour faire ça, la manière la plus simple c'est de faire une égalité structurelle.

Comment vous feriez ?