vecteur héritage c++

Bonjour,

Je vais expliquer mon problème par un exemple.

J'ai 4 class, une class mère, une class fils1, une class fils2 et une class3

les class fils héritent de class mère.

Dans mon main j'ai un vecteur (vecteur <mere*>), donc lors d'un nouveau class1, class2 ou class3 je le place dans ce vecteur.

Ce que je voudrais savoir c'est s'il y a un moyen de savoir lorsque je manipule les class qui se trouvent dans mon vecteur, qu'elle class je manipule ou est-ce que je dois ajouter un attribut en plus.

Merci pour votre aide.

Non, tu peux pas savoir.
Une bonne question, c'est "pourquoi tu veux savoir ?" ;)
Sinon une solution qui marche c'est un truc du genre :

Code:

---

1 2 3 4

class Base { virtual const std::string GetTypeName const () = 0; };

---

Tu fais hériter tes classes de Base, et dans tes classes tu redéfinis la méthode GetTypeName :

Code:

---

1 2 3 4

class Mere : public Base { virtual const std::string GetTypeName const () {return "Mere";} };

---

Tu peux faire une macro pour automatiser ça...

Mias surtout, répond d'abord à la question importante: Pourquoi en ai-je besoin?
C'est à dire:
Pourquoi mettrai-je des choses différentes dans le même tas, si c'est pour les traiter différemment?
Il y a deux façons de réfléchir à ce problème:

• N'aurai-je pas du faire plusieurs tas? c'est à dire utiliser plusieurs vecteurs
• Ne puis-je pas faire en sorte d'agir de la même façon? utiliser l'héritage et la virtualité permet d'avoir des réactions différentes à une même stimulation

Citation:

---

Envoyé par hbenji

Ce que je voudrais savoir c'est s'il y a un moyen de savoir lorsque je manipule les class qui se trouvent dans mon vecteur, qu'elle class je manipule ou est-ce que je dois ajouter un attribut en plus.

---

Bonjour,

Tu peux récupérer le type à l'aide du pattern visiteur, ça donne quelque chose du genre :

Code:

---

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

struct Visitor { void operator()(Class1& c) { /* code spécifique à Class1 */ } void operator()(Class2& c) { /* code spécifique à Class2 */ } };   struct Mere { ... virtual void accept(V& visitor) = 0; }   struct Class1 { ... virtual void accept(V& visitor) { v(*this); } }   struct Class2 { ... virtual void accept(V& visitor) { v(*this); } }   std::vector<Mere*> vec; ... Visitor v; for(auto ptr: vec) { ptr->accept(v); }

---

Citation:

---

Envoyé par leternel

Pourquoi mettrai-je des choses différentes dans le même tas, si c'est pour les traiter différemment?

---

Il arrive de devoir faire une opération a() sur tous les éléments, et une opération b() seulement sur un seul type par exemple. Mais effectivement, la question est à se poser.

Citation:

---

Envoyé par hbenji

Ce que je voudrais savoir c'est s'il y a un moyen de savoir lorsque je manipule les class qui se trouvent dans mon vecteur, qu'elle class je manipule ou est-ce que je dois ajouter un attribut en plus.

---

Il y a la solution du dynamic_cast, qui n'est généralement pas des plus heureuses.

Citation:

---

Envoyé par oodini

Il y a la solution du dynamic_cast, qui n'est généralement pas des plus heureuses.

---

C'est vrai c'est pas toujours heureux mais il y a parfois des cas où c'est une bonne solution. ;)

Citation:

---

Envoyé par Iradrille

Il arrive de devoir faire une opération a() sur tous les éléments, et une opération b() seulement sur un seul type par exemple. Mais effectivement, la question est à se poser.

---

Dans ce cas, pourquoi de l'héritage ?
Si l'on doit réaliser un traitement différent, que l'on ne peut factoriser dans les services ou comportements de la classe, l'héritage est superflu non non avenu.

Je suis tout à fait en désaccord.

Cela signifierait que les classes filles ne peuvent offrir que les services offerts par la classe mère, et ne peuvent définir aucune autre nouvelle fonction. C'est une curieuse conception de la programmation objet.

Ce sur quoi on peut s'interroger, c'est sur la pertinence de tout mettre dans un seul vecteur.

Citation:

---

Envoyé par Bousk

Dans ce cas, pourquoi de l'héritage ?
Si l'on doit réaliser un traitement différent, que l'on ne peut factoriser dans les services ou comportements de la classe, l'héritage est superflu non non avenu.

---

Je plussoie.
C'est décidément un problème à la mode ces temps-ci.
Pourquoi vouloir faire une hiérarchie de classe si chaque classe a un protocole différent? ça ne fait que rajouter des complications et ça n'apporte rien.
C'est comme les templates; parfois je vois du code où on voit clairement que le développeur à voulu absolument utiliser des templates alors que ça n'apporte que, dans le meilleur des cas, de la complexité au code.

Citation:

---

Envoyé par oodini

Je suis tout à fait en désaccord.

Cela signifierait que les classes filles ne peuvent offrir que les services offerts par la classe mère, et ne peuvent définir aucune autre nouvelle fonction. C'est une curieuse conception de la programmation objet.

Ce sur quoi on peut s'interroger, c'est sur la pertinence de tout mettre dans un seul vecteur.

---

Les classes fille peuvent redéfinir des méthodes, mais il s'agira de méthodes privées et qu'elles seules, et ceux qui travaillent avec elles en tant que telles (et non en tant que Mere mais en fait c'est une Fille), peuvent utiliser. Et certainement pas quelqu'un qui travaille avec une Mere.

Si la classe Mere définit une interface doStuff(), la classe fille pourra faire doStuff(), voire doStuff2(), doStuff() de la fille pourra même n'être qu'une indirection vers son propre doStuff2() mais à aucun moment on ne doit avoir besoin d'appeler doStuff2() sur une Mere, et à raison : ça n'existe pas.

Citation:

---

Envoyé par oodini

Cela signifierait que les classes filles ne peuvent offrir que les services offerts par la classe mère, et ne peuvent définir aucune autre nouvelle fonction. C'est une curieuse conception de la programmation objet.

---

Pas si cette fonction est publique, en effet.
Et c'est une conception de la poo qui est très partagée dans la communauté et ce principe porte même un nom, le principe de substitution de Liskov.

Respecter ce principe reviens à respecter le principe est-un de l'héritage tel qu'il a été conçu en c++, et il apporte beaucoup d'avantages concrets dans le développement. Je ne développerai pas ici, mais effectue une recherche sur LSP et tu trouveras des informations beaucoup plus pertinentes que je ne serais capable de produire.

Salut,

De manière générale, tu peux (comprends: il est tout à fait légal de le faire :D) envisager de fournir une méthode qui permet de récupérer le type réel de ton pointeur et de travailler à coup de dynamic_cast.

Cela pourrait prendre la forme de

Code:

---

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 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

enum ClassType { fils1, fils2, fils3 }; class Mere { public: virtual ClassType type() const = 0; }; class Fils1 : public Mere { public: virtual ClassType type() const {return fils1;} }; class Fils2 : public Mere { public: virtual ClassType type() const {return fils2;} }; class Fils3 : public Mere { public: virtual ClassType type() const {return fils3;} };   int main() { std::vector<Mere*> tab; /* ... */ for(auto it : tab) { switch(it->type()) { case fils1: Fils1 * temp= dynamic_cast<Fils1*>(it); /* ... */ break; case fils1: Fils2 * temp= dynamic_cast<Fils2*>(it); /* ... */ break; case fils1: Fils3 * temp= dynamic_cast<Fils3*>(it); /* ... */ break; } } }

---

Mais je te déconseille très fortement et avec la plus grand insistance de faire de la sorte :aie:

En effet, si tu choisis cette option, tu vas très rapidement te retrouver dans une situation dans laquelle tu passeras ton temps à tester le type réel de tes objets (ou plutôt de tes pointeurs ou de tes références) avant de les transtyper afin de pouvoir les utiliser.

Cela va mener à une complexification systématique et largement inutile de ton code et cela va présenter un inconvénient majeur:

Si tu décides, un jour, de rajouter une classe dérivée (et les raisons pour le faire sont nombreuses, la question n'est donc pas de savoir SI tu voudras le faire, mais bien QUAND tu voudras le faire :D), tu devras reprendre systématiquement tout ton code pour prendre cette nouvelle classe en compte :aie:

L'idéal est donc de se baser sur le principe du double dispatch:

L'idée est de se dire que les pointeurs connaissent leur type réel.

Il est donc possible d'envisager un comportement que l'on appellera au départ de "tout objet passant pour être du type de base" qui s'adaptera au type réel de l'objet.

Le principe du visiteur se base sur un principe similaire ;)

Si c'est pour être utilisé comme ça, aucun intérêt à utiliser un dynamic_cast au lien d'un static_cast, moins coûteux.

Citation:

---

Envoyé par oodini

Si c'est pour être utilisé comme ça, aucun intérêt à utiliser un dynamic_cast au lien d'un static_cast, moins coûteux.

---

En effet, mais, comme je déconseille fortement de recourir à cette technique... :D

Quel débat, déjà merci pour votre aide

enfaite ceux que je veux faire c'est que: (en reprenant mon exemple)

1) dans le main c'est d'avoir un seul vecteur pour toutes les class ou si ce n'est pas possible avoir un vecteur pour chaque class, je ne sais pas quel est le meilleur choix.

2) la class mère possède un vecteur d'objets de type A par exemple, donc les 3 class fils héritent de ce vecteur et le problème c'est que A possède un fils B et C mais fils1 et fils2 ne peuvent pas avoir d'objet de type B dans leur vecteur alors que fils3 peut en avoir, c'est surtout pour ça que je voulais savoir si on peut connaitre le type d'un objet s'il c'est de type B ou de type C.

Merci encore.

Citation:

---

Envoyé par r0d

Respecter ce principe reviens à respecter le principe est-un de l'héritage tel qu'il a été conçu en c++, et il apporte beaucoup d'avantages concrets dans le développement. Je ne développerai pas ici, mais effectue une recherche sur LSP et tu trouveras des informations beaucoup plus pertinentes que je ne serais capable de produire.

---

Le principe de substitution de Liskov dit juste qu'on doit concevoir nos classes de telle manière que partout où une classe de base est attendue, on puisse la substituer par une classe dérivée, est que tout se passe bien. Il n'interdit pas à une classe dérivée de proposer des services supplémentaires.

Citation:

---

Envoyé par koala01

Salut,

De manière générale, tu peux (comprends: il est tout à fait légal de le faire :D) envisager de fournir une méthode qui permet de récupérer le type réel de ton pointeur et de travailler à coup de dynamic_cast.

---

Franchement, je déconseille encore plus l'utilisation d'une telle méthode que l'utilisation du dynamic_cast brut de fonderie.

Pourquoi ? Parce que dans la quasi-totalité des cas, une telle méthode marche mal avec plusieurs niveaux d'héritage, là où dynamic_cast marche (C dérive de B dérive de A, on peut dynamic_caster un A* en B* si l'objet pointé est de type C). En plus, je ne vois aucun apport de cette méthode (à part le risque de fautes de frappe dans les chaînes de caractère non repérées par le compilateur, et les performances moins bonnes).

Citation:

---

Envoyé par JolyLoic

Franchement, je déconseille encore plus l'utilisation d'une telle méthode que l'utilisation du dynamic_cast brut de fonderie.

Pourquoi ? Parce que dans la quasi-totalité des cas, une telle méthode marche mal avec plusieurs niveaux d'héritage, là où dynamic_cast marche (C dérive de B dérive de A, on peut dynamic_caster un A* en B* si l'objet pointé est de type C). En plus, je ne vois aucun apport de cette méthode (à part le risque de fautes de frappe dans les chaînes de caractère non repérées par le compilateur, et les performances moins bonnes).

---

Oh, tu as coupé ma citation beaucoup trop tot :D

Je dis qu'il est légal de le faire, que c'est autorisé par le langage, mais je dis aussi qu'il est très largement recommandé d'éviter de le faire, non :question:

Disons qu'il y a deux aspects :
1 - Le fait de tester le type réel d'un objet, quel que soit la manière
2 - La manière de tester ça.

Pour moi, le reste de ta citation s'attachait à dire que le point 1 était mauvais. Et sur ce point, je suis à 100% avec toi.

Mon intervention avait pour but de dire que si, on voulait passer outre, la manière dont tu proposais de le faire dans ton exemple n'était pas la meilleure. Je préfère largement (bien que je n'aime quand même pas) du code qui ressemblerait à :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

for(auto it : tab) { Fils1 * fils1= dynamic_cast<Fils1*>(it); if (fils1 != nullptr) { /* ... */ } else { Fils2 * fils2= dynamic_cast<Fils2*>(it); if (fils2 != nullptr) { /* ... */ } } }

---

Citation:

---

Envoyé par Bousk

Les classes fille peuvent redéfinir des méthodes, mais il s'agira de méthodes privées et qu'elles seules, et ceux qui travaillent avec elles en tant que telles (et non en tant que Mere mais en fait c'est une Fille), peuvent utiliser. Et certainement pas quelqu'un qui travaille avec une Mere.

---

Disons que j'ai une classe mère Véhicule, qui a deux classes filles Voiture et Vélo.
En gros, tu m'interdis de créer le service démarrer() pour la classe Voiture, parce qu'elle n'est pas factorisable dans la classe Véhicule (on ne démarre pas un vélo).
Je suis supposer la pousser, ma voiture ?

Citation:

---

Envoyé par Bousk

Si la classe Mere définit une interface doStuff(), la classe fille pourra faire doStuff(), voire doStuff2(), doStuff() de la fille pourra même n'être qu'une indirection vers son propre doStuff2() mais à aucun moment on ne doit avoir besoin d'appeler doStuff2() sur une Mere, et à raison : ça n'existe pas.

---

Je ne vois pas en quoi ce que tu dis interdit de définir une nouvelle méthode sur la classe file.

Tu confonds tout et cherches la petite bête dans mes propos...

Tu déclares toutes les méthodes que tu veux dans ta classe fille, mais tu n'es sensé manipuler que les méthodes de la classe mère si tu utilises un pointeur vers mere. Il est juste hors de question de faire un if ou quoi que ce soit pour dire "non mais mere là en fait c'est fille, alors j'apelle la méthode spécifique fille".
Si tu as besoin d'utiliser une méthode spécifique fille, tu travailles avec une fille.

Citation:

---

Je ne vois pas en quoi ce que tu dis interdit de définir une nouvelle méthode sur la classe file.

---

Parce qu'encore une fois, tu veux comprendre ce que tu veux de mes propos.
Tu définis ce que tu veux pour ta classe fille, mais seules les méthodes virtuelles et héritées définissent l'interface de la mere, et donc de la fille. Les méthodes utilisent ce qu'elles veulent en interne à fille, y compris des méthodes propres à fille, mais c'est de l'implémentation interne.

Si tu étends l'interface de fille, ce n'est que de fille et non de mere. Donc soit tu manipules une fille, soit tu utilises l'interface de mere.

Citation:

---

Disons que j'ai une classe mère Véhicule, qui a deux classes filles Voiture et Vélo.
En gros, tu m'interdis de créer le service démarrer() pour la classe Voiture, parce qu'elle n'est pas factorisable dans la classe Véhicule (on ne démarre pas un vélo).
Je suis supposer la pousser, ma voiture ?

---

Qui interdit d'avoir une méthode vehicule::demarrer ? A part toi personne ici.
Qui a dit qu'une méthode devait toujours faire qqch ? Qui interdit un vélo de démarrer et de ne rien faire sur une telle action ?
Par contre oui je t'interdis, puisque tu sembles apprécier ce terme, de faire un appel à demarer de voiture alors que tu manipules un vehicule qui ne détermine pas cette fonction.
Et plus fort que ça, ton compilateur te l'interdira tout bonnement.

Citation:

---

Les classes fille peuvent redéfinir des méthodes, mais il s'agira de méthodes privées et qu'elles seules, et ceux qui travaillent avec elles en tant que telles (et non en tant que Mere mais en fait c'est une Fille), peuvent utiliser. Et certainement pas quelqu'un qui travaille avec une Mere.

---

Je suppose que tu chipottes pour le privé, qui est là pour distinguer de l'interface héritée de mere et non du mot-clé private.
Alors relis bien le reste de la phrase peut-être.

Citation:

---

elles seules, et ceux qui travaillent avec elles en tant que telles (et non en tant que Mere mais en fait c'est une Fille), peuvent utiliser. Et certainement pas quelqu'un qui travaille avec une Mere

---

Citation:

---

Envoyé par Bousk

Tu confonds tout et cherches la petite bête dans mes propos...

---

C'est toi qui confond. Je répondais initialement à cette phrase de ton cru :

Si l'on doit réaliser un traitement différent, que l'on ne peut factoriser dans les services ou comportements de la classe, l'héritage est superflu et non avenu.

Citation:

---

Envoyé par Bousk

Tu déclares toutes les méthodes que tu veux dans ta classe fille, mais tu n'es sensé manipuler que les méthodes de la classe mère si tu utilises un pointeur vers mere.

---

C'est bien pour ça que j'avais précisé :

Ce sur quoi on peut s'interroger, c'est sur la pertinence de tout mettre dans un seul vecteur.

Citation:

---

Envoyé par Bousk

Si tu as besoin d'utiliser une méthode spécifique fille, tu travailles avec une fille.

---

Ben voilà. Exactement ce que je propose implicitement ci-dessus, par l'utilisation d'un second conteneur de classes filles ayant besoin du traitement spécifique.

Citation:

---

Envoyé par Bousk

Il est juste hors de question de faire un if ou quoi que ce soit pour dire "non mais mere là en fait c'est fille, alors j’appelle la méthode spécifique fille".

---

À aucun moment je n'ai encouragé cette manière de faire. J'ai à un moment évoqué dynamic_cast, mais en disant que ce n'était généralement pas une solution très heureuse.

Citation:

---

Envoyé par Bousk

Parce qu'encore une fois, tu veux comprendre ce que tu veux de mes propos.

---

J'ai l'impression inverse, désolé.
Interroge-toi sur la pertinence de ta première réponse à l'attention de mon auguste personne.

Citation:

---

Envoyé par Bousk

Tu définis ce que tu veux pour ta classe fille, mais seules les méthodes virtuelles et héritées définissent l'interface de la mere, et donc de la fille. Les méthodes utilisent ce qu'elles veulent en interne à fille, y compris des méthodes propres à fille, mais c'est de l'implémentation interne.

Si tu étends l'interface de fille, ce n'est que de fille et non de mere. Donc soit tu manipules une fille, soit tu utilises l'interface de mere.

---

Mais à quel moment ai-je tenu une position inverse ?

Citation:

---

Envoyé par Bousk

Qui interdit d'avoir une méthode vehicule::demarrer ?

---

Le bon sens.
Les classes filles doivent offrir une implémentation de l'interface décrite par la classe mère.
Or, un vélo, ça ne se démarre pas.

Citation:

---

Envoyé par Bousk

A part toi personne ici.

---

Apparemment, tu as déjà en main des sondages sur cette question.

Citation:

---

Envoyé par Bousk

Qui a dit qu'une méthode devait toujours faire qqch ? Qui interdit un vélo de démarrer et de ne rien faire sur une telle action ?

---

Mais bien sûr : quel constructeur va donc mettre sur un vélo un démarreur qui ne fait rien ?

Tu offres dans les services de vélo un service qui ne fait rien : tu mens.
Tu peux aussi mettre une fonction faireLePlein(), si tu veux.

Citation:

---

Envoyé par Bousk

Je suppose que tu chipottes pour le privé, qui est là pour distinguer de l'interface héritée de mere et non du mot-clé private.

---

Je n'en ai ni le besoin, ni l'envie.

Citation:

---

Envoyé par Bousk

Alors relis bien le reste de la phrase peut-être.

---

Relis bien ta première réponse à mon attention, et interroge-toi sur sa pertinence.

Citation:

---

Envoyé par Bousk

Qui interdit d'avoir une méthode vehicule::demarrer ? A part toi personne ici.
Qui a dit qu'une méthode devait toujours faire qqch ? Qui interdit un vélo de démarrer et de ne rien faire sur une telle action ?
Par contre oui je t'interdis, puisque tu sembles apprécier ce terme, de faire un appel à demarer de voiture alors que tu manipules un vehicule qui ne détermine pas cette fonction.
Et plus fort que ça, ton compilateur te l'interdira tout bonnement.

---

A vrai dire, rien dans le langage ne t'interdira de prévoir une fonction (quelle qu'elle soit et quoi qu'elle fasse... ou non) dans la classe mère, mais, en terme de conception, il y a surement matière à chicaner

Il faut se rappeler que la décision de déclarer et de définir une fonction membre est une décision conceptuelle, car on estime que cette fonction fait partie des services que l'on est en droit (ou que l'on croit être en droit :D) d'attendre de la part de la classe que l'on crée, et qu'aucun langage ne sera jamais armé pour juger de l'opportunité d'un choix de conception ;)

Par contre, ce qui t'interdira normalement de déclarer une fonction virtuelle pure "demarrer" dans une classe Véhicule, c'est le LSP :aie:

En effet, LSP t'impose que toute propriété valide pour la classe de base soit également valide pour la classe dérivée.

En ce sens, si tu déclares une fonction "demarrer" dans la classe véhicule, il faut que cette fonction ait un sen pour toutes les classes qui héritent (ou qui hériteront) de véhicule.

Si on estime (et je fais partie de ceux qui l'estiment :D) qu'il n'y a aucun sens à avoir une fonction démarrer pour un vélo alors qu'elle existe au niveau de la classe Véhicule, nous nous trouvons avec une propriété valide pour la classe Véhicule qui est invalide pour la classe Vélo, et donc, l'héritage est conceptuellement interdit au termes de LSP.

Si tu retires cette fonction de l'interface de Véhicule et que tu ne garde que, dans Véhicule, que des fonctions qui ont un sens quel que soit le type réel de véhicule envisagé (aussi bien la voiture, le vélo que les patins à roulettes :D), alors tu te trouves dans une situation dans laquelle LSP est respecté, et l'héritage admis ;).

Mais cela nous ramène de plein pied au problème d'origine: cette fonction démarrer ne se retrouvera que dans l'interface de certaines classes dérivées de Véhicule, et il s'agira donc d'accéder aux instances de ces classes sous la forme d'un pointeur (ou d'une référence) sur leur type réel.

Et comme tu as raison de dire qu'il ne faut à aucun prix accepter une logique de transtypage (quel que puisse être la manière dont il est envisagé), il s'agit de mettre en place d'autres solutions:

• Soit en maintenant séparément des listes des différents types de véhicules que l'on manipule
• Soit en recourant au double dispatch ;)