utilisation de typeid

Bonjour,

j'ai une méthode qui n'est pas redéfinit dans ses classes filles car identique dans tous les cas jusqu'à maintenant.

J'aimerais néanmoins, sans modifier ce détail car le code est trop important pour être autant modifier pour une simple correction(et puis je ne peux pas trop modifier le code de toute façon), pouvoir tester dans la classe mère, si le type de l'objet courant est d'un certain type :

if (typeid(this) != typeid(MaClasseFille*).

if (typeid(this).name != "MaClasseFille*")
j'ai testé ceci, mais dans le premier cas, le compilo me sort un "undeclared identifier" et dans le second un problème de conversion :

Code:

---

1 2 3 4 5 6

error C2040: '!=' : 'const char *(__thiscall type_info::* )(void) const' differs in levels of indirection from 'const char [16]' error C2446: '!=' : no conversion from 'const char *' to 'const char *(__thiscall type_info::* )(void) const' There is no context in which this conversion is possible error C2475: 'type_info::name' : forming a pointer-to-member requires explicit use of the address-of operator ('&') and a qualified name error C2475: 'type_info::name' : forming a pointer-to-member requires explicit use of the address-of operator ('&') and a qualified name

---

Auriez-vous une idée de comment je peux m'en sortir sans trop de casse ? :)

Edit :
pour la première version, je comprend bien que ce soit délicat pour une classe mère d'identifier "ses filles", mais je le mets au cas où vous auriez des infos à ce sujet.

J'ai vu que typeid était plus performant qu'un dynamic_cast<type> ou qu'un std::typeinfo, c'est vrai ? (et je savais pas qu'un dynamic_cast servait à cela).



EDIT2 : problème réglé, j'ai appelé la méthode name(), par contre il me retourne toujours le type de la classe mère (je sais en l'état c'est normal, je suis bête :mrgreen:).

Du coup ma question se résume à : comment je fais pour savoir de quel classe fille est issue l'appel à ma méthode ?

Salut,

Dans le premier cas, c'est normal : la classe mère ignore tout des classes qui en héritent ;)

Il faudrait, pour que typeid(this) == typeid(MaClasseFille*) que le compilateur connaisse au minimum le type de MaClasseFille, ce qui serait une énorme erreur de conception ;)

Et, de manière générale, je te déconseille fortement de faire appel à un type dérivé dans la classe de base ;)

J'aurais déjà tendance à te conseiller de vérifier si la fonction en question est virtuelle ou non, car, si elle ne l'est pas, c'est que le concepteur de la classe de base ne considérait pas utile que cette fonction soit redéfinie (et il n'y a normalement pas à le faire :D ) ;)

Si la fonction est virtuelle et que tu souhaites récupérer le code correspondant à l'exécution de la classe de base, il t'est toujours possible d'invoquer explicitement ce comportement:

Code:

---

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

void DerivedClass::doSomething() /* const */ { /* ce qui doit etre effectué avant l'appel explicite du code de la classe   * mère   *   */ BaseClass::doSomething();   /* ce qui doit etre effectué après l'appel explicite du code de la classe   * mère   *   */ }

---

Si cela ne t'est pas possible, parce que, par exemple, la partie spécifique à effectuer devrait se placer "au bon milieu" de la version propre à la classe mère, c'est très certainement que cette fonction en fait trop et mériterait amplement d'être revue de manière à factoriser une partie de son code ;)

Citation:

---

Envoyé par koala01

Salut,

Dans le premier cas, c'est normal : la classe mère ignore tout des classes qui en héritent ;)

---

Oui, c'est ce que je me suis dépêché de dire dans mon premier edit :oops:

Citation:

---

Envoyé par koala01

Et, de manière générale, je te déconseille fortement de faire appel à un type dérivé dans la classe de base ;)

---

ça ne me plait pas trop non plus...

Citation:

---

Envoyé par koala01

J'aurais déjà tendance à te conseiller de vérifier si la fonction en question est virtuelle ou non, car, si elle ne l'est pas, c'est que le concepteur de la classe de base ne considérait pas utile que cette fonction soit redéfinie (et il n'y a normalement pas à le faire :D ) ;)

---

non virtuelle... et le concepteur avait raison de le considérer à l'époque, mais depuis, des classes filles ont vu le jour, et elles ont toutes le travail de la méthode non-virtuelle à accomplir, alors qu'il faudrait qu'une seule seulement s'en occupe...

Je peux créer une méthode virtuelle qui encapsule la partie du traitement concerné, et que je redéfini juste dans ma nouvelle classe fille a priori .... pas d'objections ?


En tout cas merci encore à vous (encore vous :lol:) d'avoir pris le temps de me répondre ;)

Citation:

---

Envoyé par Kaamui

Oui, c'est ce que je me suis dépêché de dire dans mon premier edit :oops:



ça ne me plait pas trop non plus...



non virtuelle... et le concepteur avait raison de le considérer à l'époque, mais depuis, des classes filles ont vu le jour, et elles ont toutes le travail de la méthode non-virtuelle à accomplir, alors qu'il faudrait qu'une seule seulement s'en occupe...

Je peux créer une méthode virtuelle qui encapsule la partie du traitement concerné, et que je redéfini juste dans ma nouvelle classe fille a priori .... pas d'objections ?


En tout cas merci encore à vous (encore vous :lol:) d'avoir pris le temps de me répondre ;)

---

Oui, mais veilles à lui donner un autre nom (ou une liste d'arguments différente), à cette fonction virtuelle qui encapsule l'ancienne fonction ;)

Autrement, tu auras des problèmes car le compilateur ne saura pas, si tu ne disposes que d'un pointeur sur la classe de base, qu'il doit aller voir si la fonction est virtuelle dans les classes dérivées ;)

salut,

typeid est une spécificité du rtti, as tu bien utilisé les bonnes options (dépendant du compilateur) pour activer ces fonctionnalités?

tu confondrais pas un peu c++ avec c#, javascript ou php par exemple? où as tu vu en c++ une surcharge des opérateurs de comparaison pour les chaine de caractère hors de l'utilisation de la classe string?

du coup forcément lui voit que tu lui demandes de comparer des choses avec des types incompatibles donc il te dit les différentes choses impossibles qu'il a essayé de faire...

si tu veux comparer des chaine y des fonction pour ça...


koala le polymorphisme, ça a pas pour but de mettre un pointeur sur la classe de base et si celui-ci pointe sur une classe dérivé faire appel aux méthodes dérivées?

le seul problème est donc de bien concevoir son modèle POO...

:ccool:

Citation:

---

Envoyé par ericd69

koala le polymorphisme, ça a pas pour but de mettre un pointeur sur la classe de base et si celui-ci pointe sur une classe dérivé faire appel aux méthodes dérivées?
:ccool:

---

Si, mais, vu que la fonction n'est pas déclarée virtuelle dans la classe de base, le fait de la rendre virtuelle dans la classe dérivée aura pour conséquence de simplement cacher la fonction de la classe de base dans la classe dérivée, sans assurer pour autant le polymorphisme :

Si tu travailles avec un pointeur (ou une référence) sur le type de base, c'est la version (non virtuelle!!) de la fonction qui sera appelée quoi qu'il arrive, meme si le pointeur pointe en réalité sur (ou la référence fait en réalité référence à) un pointeur du type dérivé :aie:

Par contre, ca marche dans l'autre sense :D : si une fonction est déclarée virtuelle dans la classe de base, elle est implicitement déclarée virtuelle dans la classe dérivée même si l'utilisateur ne précise plus qu'elle l'est :D

Un exemple pour comprendre
Ce qui ne marche pas

Code:

---

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

class BadBase { public: void doSomething(); // fonction non virtuelle }; class BadDerieved : public BadBase { public; virtual void doSomething(); // cache la déclaration (non virtutelle) // de BadBase::doSomething(); }; int main() { BadDerived d; d.doSomething(); // OK : appel de BadDerived::doSomething() BadBase * ptr = new BadDerived; ptr->doSomething(); // KO : appel de BadBase::doSomething() }

---

ce qui marche

Code:

---

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

class Base { public: virtual void doSomething(); // fonction explicitement virtuelle }; class Derived : public Base { public: void doSomething(); // fonction implicitement virtuelle car elle est // déclarée virtuelle dans la classe de base }; int main() { Derived d; d.doSomething(); // pas de polymorphisme en jeu ici :D Base * ptr = new Derived; ptr->doSomething(); // OK : Base::doSomething() est virtuelle, // le polymorphisme fonctionne }

---

Au fait, comme cela j'aurai été complet :D

Si le destructeur de la classe de base est publique et non virtuel, la classe n'a pas à être dérivée!!!

Dans ce cas, la "moins mauvaise" solution est sans doute d'envisager de créer une composition / agrégation avec une nouvelle classe qui expose des fonctions similaires, mais virtuelles, et dont les classes spécialisées pourraient hériter ;)

certes mais je le vois pas parti pour ça :aie:

Citation:

---

Envoyé par ericd69

certes mais je le vois pas parti pour ça :aie:

---

Bien, si tu relis la discussion depuis le début, tu constateras que le problème vient du besoin de faire évoluer quelque chose qui , pour le malheur de Kaamui, n'avait apparemment pas été prévu pour évoluer.

Je suis déjà sur le point de penser que le recours lui-même à 'héritage avec la classe existante mériterait amplement d'être réévalué très sérieusement et qu'il convient non seulement de s'assurer qu'il y ait un sens à faire hériter une nouvelle classe de celle-ci (que le LSP soit effectivement respecté) mais aussi de s'assurer que la classe dont on veut faire hériter les nouvelles ait vocation à être dérivée :aie:

Le gros problème, c'est que l'on est loin d'en savoir assez sur la classe existante ni sur les nouvelles classes à créer pour avoir une chance de se faire un opinion définitive!!!

La seule chose que l'on sait, c'est que, telle qu'elle est prévue, la fonction qui intéresse Kaamui n'a pas vocation à être redéfinie, vu qu'elle n'est pas déclarée comme virtuelle, et que OCP aidant, je estime (peut etre à tord, cela peut se discuter :D ) que le fait de rendre la fonction virtuelle dans la classe existante n'est ni fait ni à faire!

A partir de là, je m'efforce de présenter les différentes solutions qui s'offrent à lui et de répondre à ta question pour le moins pertinente, le tout en essayant d'attirer autant que faire se peut l'attention sur les problèmes qu'il peut y avoir à envisager d'hériter d'une classe qui n'a pas été conçue pour et de donner les possibilités qui s'offrent pour contourner le problème :D

oui comme souvent... les gens essaye de "simplifier" le problème pour le rendre "compréhensible" aux autres et du coup... ils donnent pas assez d'info ou présentent des trucs qui reflète pas du tout le vrai problème...

bref on verra bien comment ça évolue :zoubi:

Désolé pour le manque d'information, mais je ne peux malheureusement en dire plus (vous comprendrez facilement pourquoi).

Pour résumer, le code en question est vieux de 10 ans facile, et en effet certains besoins ont évolués, et certains ne pouvaient tout simplement pas être prévus par les concepteur de l'époque. Le problème, c'est que pour les personnes qui veulent voir le programme évoluer, la manière importe peu. Et pour cela je remercie très fortement Koala01 d'avoir joué le jeu de se placer dans ce contexte difficile, qui bien sur devrait se régler conceptuellement, mais qui, vu l'ampleur des dégâts, contraignait à du bidouillage (au final la demande était une petite évolution, alors chambouler l'architecture n'était pas permis (même si ce serait graaandement nécessaire).

Pour le fin mot de l'histoire, le client a changé d'avis avant qu'on est besoin de faire un choix entre bidouillage et re-conceptualisation :mouarf:


Merci à tous !