tester si un champs existe dans une classe, est-ce possible ?

Bonjour,

J'ai une classe abstraite Personne (un nom et un prenom) et après j'ai des classes filles Etudiant (annee) et Prof (matiere) qui chacun contient un nouveau champ particulier.

Par la suite, j'aimerais savoir respectivement combien j'ai d'Etudiant et combien j'ai de Prof dans ma liste de Personne.

Alors j'aimerais savoir si c'est possible de parcourir la liste et en testant à chaque fois sur chaque personne si il y a le champ matiere par exemple, c'est un prof donc j'incrémente de +1 un compteur... etc

Ou alors je suis obligé de passé par un champ type a introduire dans ma classe personne pour pouvoir les différencier ?

Merci

++

Salut,

Tu as deux solutions:

La première consiste à créer un champs (énumération, pourquoi pas :question:) qui indiquera s'il s'agit d'un prof ou d'un eleve.

La deuxième consiste à essayer d'effectuer un dynamic_cast de ta personne en (éleve, par exemple).

Si le pointeur renvoyé par le dynamic_cast est nul, c'est que la conversion a échoué, et donc que ce n'est pas une personne du type que tu espérais obtenir... sinon, c'est que c'est que tu as bien affaire au type testé :D

Mais autrement, il n'y a pas vraiment de moyen de vérifier la présence d'un champs, en dehors de la possibilité de tester si un pointeur est NULL ou non... et comme il n'y aurait aucun sens à mettre les champs propres aux profs et les champs propres au élèves sous forme de pointeur dans ta classe abstraite... et que tu te retrouverais confronté à l'éternel problème de la gestion de pointeur...

La deuxième solution me va très bien mais comment on fait un dynamic_cast ? La différence avec un cast ?

Enfin comment on fait concrètement quoi ?

Merci
++

ben en gros

Code:

---

1 2 3 4

if(dynamic_cast<Eleve*> (tapersonne)!=NULL) /*C'est un éleve */ else /*C'est un prof */

---

(ici, tapersonne est un pointeur... donc, prend l'adresse de la variable si ce n'est pas le cas :D)

Oki merci impeccable ;) on en apprend tous les jours lol

Merci

Bonne soirée

Je considère que le coup du dynamic_cast pour savoir si ta variable est un prof ou un élève relève une mauvaise conception de ton programme.

Je suis d'accord que l'on peut se poser la question de l'utilité de faire cohabiter dans un seul et même conteneur des élèves avec des professeurs...

Je suis aussi d'accord avec le fait qu'il serait peut être utile de réviser l'interface de la classe abstraite.

Mais, d'un autre côté; il peut arriver que certaines circonstances nous mettent dans une situation dans laquelle, on se trouve face à l'obligation, pour un point bien précis, et pour permettre de rejoindre d'autres besoins ailleursd'envisager le dynamic_cast pour déterminer le type réel d'objet auquel on a affaire...

Dés lors, avant de juger, il faudrait peut être chercher à en savoir plus :D

Même.
S'il souhaite faire cohabiter des prof et des élèves c'est normalement pour utiliser le polymorphisme.
Or, caster une personne en prof ou élève revient à casser temporairement le polymorphisme (ce qui me semble asurde).

Après , s'il souhaite vraiment avoir une méthode pour obtenir le type de l'objet, je pencherai plutôt pour quelque chose du genre :

Code:

---

1 2 3 4 5 6 7 8 9

if(tapersonne->GetType() == "Eleve") { //c'est un élève } else { //c'est un prof }

---

Citation:

---

Envoyé par Davidbrcz

Après , s'il souhaite vraiment avoir une méthode pour obtenir le type de l'objet, je pencherai plutôt pour quelquechose du genre :

---

A part que c'est plus lent, que ça demande plus de code et que ça ne marche pas bien avec des hiérarchies plus profondes, c'est quoi l'avantage par rapport à un dynamic_cast ?

il faudrait qu'il nous dise ce qui l'empêche de faire une liste de profs et une liste d'élèves.

Ben en fait le but c'est d'avoir une liste de personnes mélangées c'est tout c'est juste un exo... ;)

Dans ce cas, dynamic_cast ira très bien.

Il est vrai que ce je propose n'est pas optimal, car :

Citation:

---

plus lent

---

: c'est sûr, appel de fonction mais avec inline ca change rien particulier.

Citation:

---

plus de code

---

: on va pas mourir pour une fonction de 2 lignes.
De plus s'il à d'autre classe dérivées , taper à chaque fois le dynamic_cast, ca vite être énervant.

Citation:

---

ça ne marche pas bien avec des hiérarchies plus profondes

---

: je ne vois pas pourquoi tu dit ça.C'est tout autant extensible que le dynamic_cast mais pas de la même manière.

Citation:

---

Envoyé par Davidbrcz

Il est vrai que ce je propose n'est pas optimal, car :
[plus lent] : c'est sûr, appel de fonction mais avec inline ca change rien particulier.

---

En l'occurence, ce n'est pas tant l'appel de fonction que la comparaison de chaîne dont je parlais. Et même en remplaçant la chaîne par une enum, il y a des chances qu'un dynamic_cast soit un cas que les compilateurs optimisent spécialement.

Citation:

---

Envoyé par Davidbrcz

[plus de code] : on va pas mourir pour une fonction de 2 lignes.
De plus s'il à d'autre classe dérivées , taper à chaque fois le dynamic_cast, ca vite être énervant.

---

Je ne vois pas quel code supplémentaire est à taper en présence d'autres classes.

Citation:

---

Envoyé par Davidbrcz

[non extensible] : je ne vois pas pourquoi tu dit ça.C'est tout autant extensible que le dynamic_cast mais pas de la même manière.

---

Supposons qu'on ait une classe professeurPrincipal qui dérive de professeur. Le code client peut vouloir dans certains cas repérer les professeurs principaux uniquement, ou bien tous les professeurs (pour ce dernier cas, y compris dans du code qui a été écrit avant que les professeurs principaux ne soient ajoutés). Que retourne la fonction GetType pour ces professeurs principaux ?

Et reste ma question initiale : Quel est le problème avec dynamic_cast ?

Citation:

---

il y a des chances qu'un dynamic_cast soit un cas que les compilateurs optimisent spécialement

---

Je ne savais pas les compilos pouvaient optilmiser le dynamic_cast.

Citation:

---

Je ne vois pas quel code supplémentaire est à taper en présence d'autres classes.

---

Bah genre :

Code:

---

1 2 3 4 5 6 7 8

if(dynamic_cast<Eleve*> (tapersonne)!=NULL) /*C'est un éleve */ else if(dynamic_cast<ProfPrincipal*> (tapersonne)!=NULL) /*C'est un prof principal */ else if(dynamic_cast<Prof*> (tapersonne)!=NULL) /*C'est un prof */ ...

---

Citation:

---

Supposons qu'on ait une classe professeurPrincipal qui dérive de professeur. Le code client peut vouloir dans certains cas repérer les professeurs principaux uniquement, ou bien tous les professeurs (pour ce dernier cas, y compris dans du code qui a été écrit avant que les professeurs principaux ne soient ajoutés). Que retourne la fonction GetType pour ces professeurs principaux ?

---

Un prof principal est un prof.
Il ssufit de faire une sorte de type extensible avec des string.
Cela pourrai donner quelque chose du genre :

Code:

---

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

if(tapersonne->GetType() == "Eleve") { //c'est un élève } else if(std::string tmp=tapersonne->GetType() && tmp=="Prof" && tmp.match("Principal") != string::npos) { //c'est un prof principal } else { C'est un prof }

---

Citation:

---

Quel est le problème avec dynamic_cast ?

---

Pour moi le problème c'est que dynamic_cast n'a pas pour vocation de vérifier si un objet est de telle type ou pas.

C'est comme lancer une voiture dans un mur pour voir la dureté du mur.
Ca marche , mais ce n'est pas le but initial de la voiture.

et alors? où est le problème?

Citation:

---

Envoyé par Davidbrcz

Code:

---

1 2 3 4 5 6 7 8

if(dynamic_cast<Eleve*> (tapersonne)!=NULL) /*C'est un éleve */ else if(dynamic_cast<ProfPrincipal*> (tapersonne)!=NULL) /*C'est un prof principal */ else if(dynamic_cast<Prof*> (tapersonne)!=NULL) /*C'est un prof */ ...

---

---

Tout l'intérêt du dynamic_cast ici, c'est que si l'utilisateur est uniquement intéressé par le statut prof/élève, il n'y a rien à faire, le code initial continue à marcher :

Code:

---

1 2 3 4

if(dynamic_cast<Eleve*> (tapersonne)!=NULL) /*C'est un éleve */ else if(dynamic_cast<Prof*> (tapersonne)!=NULL) /*C'est un prof, principal ou pas, on s'en moque */

---

Citation:

---

Envoyé par Davidbrcz

Pour moi le problème c'est que dynamic_cast n'a pas pour vocation de vérifier si un objet est de telle type ou pas.

---

Pourtant, la vérification de type est bien ce qui différencie un dynamic_cast d'un static_cast, et c'est donc de mon point de vue une vocation essentielle du mécanisme. De plus, la plupart du temps, quand on a besoin de connaître le type, c'est pour ensuite appeler des fonctions spécifiques à ce type, et dynamic_cast nous a en plus fourni un moyen de le faire.

Il faut bien être conscient qu'un prof risque d'avoir une série de méthodes que l'élève n'a pas et qui n'ont aucune place dans la classe "personne", et que l'inverse est d'ailleurs aussi vrai.

En gérant ta liste de personne, il n'est dés lors pas exclu que tu doive pouvoir disposer de ces méthodes particulières, et, pour en disposer, le dynamique_cast restera sans doute la meilleure solution, vu que, de toutes façon, tu devrait faire appel à ta méthode get_type, puis quand meme effectuer une conversion dans le bon type

Je comprend très bien votre point de vue et j'admet qu'il est plus pertinant dans ce cas.
Mais je continue a camper sur mes positions à savoir que j'éviterai au maximum que je pourrai l'utilisation d'un dynamic_cast pour déterminer le type d'un objet.

Franchement, j'ai du mal à comprendre ton point de vue. Le but ici est de retrouver le type exact de ta variable, non?
Pourquoi commencer à mettre en place une mécanique qui t'es propre et que tu dois mettre au poit et coder toi-même (avec tout les risques d'erreurs que cela comporte) alors que nativement le langage te propose une solution fiable et simple à mettre en oeuvre?

Citation:

---

Envoyé par JolyLoic

Et même en remplaçant la chaîne par une enum, il y a des chances qu'un dynamic_cast soit un cas que les compilateurs optimisent spécialement.

---

A part le fait qu'une éventuelle analyse statique puisse trouver le résultat par avance, tu penses à quoi comme optimisation? Parce qu'a priori, un dynamic_cast me semble plus coûteux qu'une fonction virtuelle renvoyant un enum.

Citation:

---

Envoyé par Davidbrcz

Mais je continue a camper sur mes positions à savoir que j'éviterai au maximum que je pourrai l'utilisation d'un dynamic_cast pour déterminer le type d'un objet.

---

dynamic_cast ne permet pas de trouver le type dynamique le plus dérivé d'un objet, il permet de vérifier si l'objet est bien d'un type donné. Il y a une différence fondamentale entre les deux.

Jean-Marc.Bourguer << Oui je comprend très bien la différence.
On trouve le type par vérification de la réussite (ou pas) du cast.
Mais bon c'était pour simplifier mon idée bien qu'au final ma simplification se soit révélé foireuse :aie:.

Citation:

---

Envoyé par Jean-Marc.Bourguet

A part le fait qu'une éventuelle analyse statique puisse trouver le résultat par avance, tu penses à quoi comme optimisation? Parce qu'a priori, un dynamic_cast me semble plus coûteux qu'une fonction virtuelle renvoyant un enum.

---

Je pensais à l'optimisation faisant qu'un dynamic_cast puisse être optimisé sous forme d'une fonction virtuelle retournant directement un ajustement de pointeur this (§5.3.8 du performance report), ce qui fait un coût de base équivalent, plus toute la magie noire qu'un compilateur peut mettre en oeuvre sur des opérations très courantes, et à laquelle je ne connais rien.

J'ai probablement été un peu optimiste en disant plus rapide, disons du même ordre de grandeur.