Transtypage dynamique : pré-requis

Bonjour,

Certains disent qu'afin d'utiliser dynamic_cast, il est nécessaire d'avoir une méthode déclarée en virtuel dans la classe mère de la classe utilisé. Voir que ce soit carrément la classe mère qui doit être déclarée en virtuel:

Code:

---

class MaClassefille : virtual public MaClasseMère

---

Et d'autre disent que rien de tout cela n'est nécessaire.

J'aimerai donc avoir votre opinion la dessus, et aussi, est ce que cette optique/obligation peut changer en fonction des bibliothèques qu'on serait susceptible d'utiliser?

ce n'est pas vraiment une opinion, c'est un fait.

pour que dynamic_cast puisse fonctionner il est necessaire que la classe aie une vtable, c'est a dire qu'elle aie au moins une methode virtuelle connue

par exemple :

Code:

---

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

class Mere { };   class Fille : public Mere { virtual void doStuff() { }; };   int main(int argc, char** argv) { Mere* fille = new Fille; dynamic_cast<Fille*>(fille)->doStuff(); }

---

refusera de compiler (le compilateur dit : "Mere is not a polymorphic type"

en revanche

Code:

---

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

class Mere { public: virtual ~Mere(); };   class Fille : public Mere { public: virtual void doStuff() { }; };   int main(int argc, char** argv) { Mere* fille = new Fille; dynamic_cast<Fille*>(fille)->doStuff(); }

---

fonctionne

Je vois que tu as déclaré le destructeur en virtual, j'ai vu dans une autre discution (que je ne pourrais pas situer pour faute d'oublie) que c'était la méthode de base (ou une convention peut être?) pour déclarer une classe polymorphique. J'aimerai donc être sûr: est ce que je peux déclarer n'importe qu'elle méthode en virtual? Même si je ne me sers pas de cette méthode ?

Tu as déclaré doStuff() en virtual aussi: est-ce nécessaire ou la aussi, on aurait pu déclarer n'importe qu'elle méthode en virtual?

En C++, la philosophie est de ne pas payer pour ce qu'on n'utilise pas. Ainsi, une classe n'ayant pas de fonction virtuelle ne possède pas les structures nécessaires pour faire du dynamic_cast. A partir du moment où une fonction virtuelle, n'importe laquelle, existe, c'est bon.

Pourquoi le destructeur ? Parce que.

D'accord, et merci.
Mais est-il aussi necessaire d'avoir une méthode virtuelle dans notre classe fille pour utiliser Dynamic_cast?
dans l'exemple de Screetch:

Code:

---

virtual void doStuff() { };

---

donc ceci est-il nécessaire?

Non, ça laisse sous-entendre qu'on peut "tranquillement" dériver la classe Fille en une classe FilleFille (:lol:) par exemple.

Salut,

En fait, le tout est, tout simplement, de comprendre ce que signifie le mot clé virtual quand il est placé devant une méthode...

En gros, cela revient à dire au compilateur:

Citation:

---

Envoyé par toi au compilateur

J'ai donné un comportement à cette méthode, qui est adapté à la classe que j'ai créée...
Mais les classes qui héritent de cette classes peuvent redéfinir ce comportement pour l'adapter à leurs besoins

---

cela revient aussi à dire au lecteur du code (toi, dans 6 mois ou un collaborateur)

Citation:

---

Envoyé par toi au lecteur

Si tu fais hériter une nouvelle classe de cette classe-ci, tu peux redéfinir le comportement de cette méthode pour l'adapter à ton cas particulier

---

Une fois que tu envisage les méthodes virtuelles sous cet angle, il devient facile de comprendre que le raisonnement du compilateur sera

Citation:

---

Envoyé par le compilateur à lui-même

Cette méthode risque d'être redéfinie par d'autres classes
Je dois donc la mettre quelque part d'où je pourrai, lors de l'appel, choisir l'implémentation en fonction du type réel de l'objet au départ duquel cette méthode est appelée

---

cet "endroit particulier" n'étant rien d'autre que... la VTable.

Puis viennent les considérations philosophiques émises par JolyLoic (qui, bien qu'elle soient "philosophiques" nécessitent d'être prises en compte): l'utilisation de la VTable a un cout, et donc, on préfère ne payer ce cout que si on en a réellement besoin (pourquoi prendre un autoroute à péage si ce n'est ni plus rapide ni moins long que si on allait par les nationnales :question:)

Citation:

---

Envoyé par JolyLoic

A partir du moment où une fonction virtuelle, n'importe laquelle, existe, c'est bon.

---

Citation:

---

Envoyé par toi au compilateur
J'ai donné un comportement à cette méthode, qui est adapté à la classe que j'ai créée...
Mais les classes qui héritent de cette classes peuvent redéfinir ce comportement pour l'adapter à leurs besoins

---

le fait de déclarer une seule méthode en virtual, permet de redéclarer n'importe quelle méthode même non virtual?

Ce qui voudrait dire (j'espère que je comprends bien):

Citation:

---

Envoyé par toi au compilateur
J'ai donné un comportement à cette méthode, qui est adapté à la classe que j'ai créée...
Mais les classes qui héritent de cette classes peuvent redéfinir les comportements de n'importe qu'elle méthode de la classe mère pour l'adapter à leurs besoins

---

Si tel est le cas, pourquoi m'arrive t-il de voir plusieurs méthodes d'une classe déclarées virtuelles?

Merci pour toutes vos réponses, elles m'aident beaucoup :)

Ca permet simplement de dire au compilateur :
Je vais laisser la possibilité aux classes filles de rédéfinir telles et telles fonctions et ce seront celles-ci qui seront appelées en temps voulu grâce au polymorphisme, mais pas les autres.

Celles que les classes filles pourront redéfinir et qui seront appelées lorsque l'on aura un pointeur ou une référence sur la classe Mère, ce sont les méthodes devant lesquelles il y aura un virtual.

Citation:

---

Envoyé par Somato

le fait de déclarer une seule méthode en virtual, permet de redéclarer n'importe quelle méthode même non virtual?

---

Excuses moi, j'ai manqué de précision... j'aurais du écrire "mais les classes qui héritent de celle-ci peuvent redéfinir cette méthode bien particulière".

Il est possible, effectivement, de redéfinir une méthode non virtuelle dans les classes filles, mais il n'y a alors aucun comportement polymorphique possible: la redéfinition de la méthode dans la classe fille "cache" ("surcharge") tout simplement celle de la classe mère...

Avec la conséquence suivante

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

/* soient les classes */ class Mere { public: void function(){/*...*/} /* tout le reste */ }; class Fille : public Mere { public: void function(){/*...*/} /* tout le reste */ };   int main() { /* aucun polymorphisme espéré */ Fille f1; f1.function(); // appelle la méthode Fille::function() /* maintenant, on espère le polymorphisme en considérant   * l'objet de type Fille comme s'il était un objet de type Mere   */ Mere *f2=new Fille(); f2->function(); //raté... on appelle la méthode Mere::function, là où // on espérait appeler Fille::function delete f2; return 0; }

---

Pour que le comportement polymorphique puisse apparaitre, il faut que la méthode appelée soit... virtuelle ;)

Alors en gros:

Code:

---

1 2 3 4 5 6 7 8 9

Class Mère public: mère(); ~mère(); virtal méthode1(); méthode2();   Class Fille : public Mère //possibilité ici de redéfinir la méthode1 si nécessaire, mais en aucun cas la méthode2?

---

Dans mon cas d'étude (et donc le cas pour le quel je me pose tant de question):

Code:

---

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

Class Mère: public: mère(); ~mère(); virtal méthode1(); méthode2();   Class Fille1 : public Mère public: fille1(); ~fille1(); virtual méthode3(); méthode4()   Class Fille2 : public Mère //je veux y réutiliser une méthode de Fille1 ... Fille1 *monObjet = new Fille1(); dynamic_cast<Fille1>(monObjet)->méthode4() //malgrès le fait que méthode4 ne soit pas virtuelle?

---

EDIT: Je vais lire le post précédent que je n'avais pas lu...
Après lecture: étant donné que Fille hérite de Mère dans mon premier code: pas besoin de virtual pour modifier les méthodes dans la classe Fille donc

Si ton pointeur est déjà déclaré comme pointant sur un objet de type Fille1, tu n'a même pas besoin d'effectuer le transtypage vers... le type qui est réellement le sien.

Si ton pointeur est déclaré comme pointant sur un objet de type Mere, alors que c'est en réalité un objet de type Fille1, il faut effectivement effectuer un transtypage vers le type adéquat pour appeler les méthodes qui ne sont pas déclarées dans la classe Mere, mais qui le sont dans la classe Fille
[EDIT]
Si, enfin, ton pointeur est déclaré comme pointant sur un objet de type Mere, alors que c'est en réalité un objet de type Fille2, la conversion échouera[/EDIT]

Ainsi une méthode de fille2 prise au hasard

Code:

---

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

void Fille2::Methode4() { Mere *obj1=new Fille1(); dynamic_cast<Fille1*>(obj1)->methode3(); //OK transtypage indispensable :D Fille1 *obj2 =new Fille1(); obj2->methode3(); //meme pas besoin de transtyper ;) Mere *obj3 = new Fille2(); dynamic_cast<Fille1*>(obj3)->methode3();//Aiie...bobo... conversion impossible obj1->methode1();//pas de problème: comportement de base obj2->methode1();//pas de problème: comportement polymorphique obj3->methode1();//pas de problème: comportement polymorphique }

---

Code:

---

dynamic_cast<Fille1*>(obj3)->methode3();//Aiie...bobo... conversion impossible

---

Comportement indéfini car dynamic_cast retournera un pointeur nul.

On n'a pas ce problème avec des références:

Code:

---

dynamic_cast<Fille1&>(*obj3).methode3()

---

Ici, le code lancera une exception std::bad_cast.

Citation:

---

Envoyé par Médinoc

Code:

---

dynamic_cast<Fille1*>(obj3)->methode3();//Aiie...bobo... conversion impossible

---

Comportement indéfini car dynamic_cast retournera un pointeur nul.

On n'a pas ce problème avec des références:

Code:

---

dynamic_cast<Fille1&>(*obj3).methode3()

---

Ici, le code lancera une exception std::bad_cast.

---

Ben, qu'il s'agisse d'une exception bad_cast lancée (mais dont la récupération n'est pas prévue), d'une erreur de segmentation (souvent observée) du fait d'une tentative de NULL->methode, du formattage du disque dur ou du lancement d'une bombe atomique sur moscou, tu avouera que cela fera de toutes manière bobo, non :question:

Sauf qu'une exception bad_cast, même non-prévue, n'est pas un comportement indéfini (appel de terminate() etc.)

Citation:

---

Envoyé par Médinoc

Sauf qu'une exception bad_cast, même non-prévue, n'est pas un comportement indéfini (appel de terminate() etc.)

---

Effectivement... je me rallie à tes arguments :D

Citation:

---

Code:

---

1 2 3 4 5

void Fille2::Methode4() { Fille1 *obj2 =new Fille1(); obj2->methode3(); //meme pas besoin de transtyper ;) }

---

---

Ce comportement peut-il changer si on utilise une bibliothèque?
Parce que dans mon cas, cela ne fonctionne pas (ou alors, il y a un petit quelque chose que j'ai omis).

Code:

---

1 2 3 4 5 6 7 8 9

class BibliClass2 : public BibliClass1 //Classes de la bibliothèque public: void methode2() {...};   class Maclass1 : public BibliClass1 public: void methode1() {BibliClass2 *obj1 = new BibliClass2(); obj1->methode2(); //error: 'class BibliClass1' has no member named 'methode2' }

---

Es tu déjà sur d'avoir inclus le fichier dans lequel est définie la BibliClass2, et non de n'avoir qu'une simple déclaration anticipée :question:

S'agit-il éventuellement d'une bibliothèque dynamique, (dll ou so selon le système d'exploitation) :question:

j'ai bien l'include.
et pardon, il ne s'agis pas d'une "bibliotèque" mais plutôt d'une "libraire" (je ne sais pas quel terme est le bon, on trouve tout sur le net, mais je me souviens avoir vu une discution ou quelqu'un démentait l'un des deux termes...).

Sans trainer autour du pot: j'utilise Qt.
(je ne pense pas aller poster à nouveau sur le forum Qt, étant donné qu'à la base, je venais chercher des informations sur les cas de fonctionnement du transtypage)

Merci de votre aide :)

C'est bien "bibliothèque" qui est le bon terme.

• .h --> Fichier d'en-tête
• .lib, .a --> Bibliothèque [à liaison] statique.
• .dll, .so --> Bibliothèque [à liaison] dynamique (souvent livrée avec une bibliothèque statique d'importation et un fichier d'en-tête).

D'acc.

Donc je suppose que l'utilisation de bibliothèque dynamique chamboule les règles de Transtypage?
(c'est ma première bibliothèque si on omet l'utilisation de Java dans mon apprentissage de la programmation qui n'a pas été si poussé que ça au départ).

Pour le transtypage dynamique, c'est possible (mais je n'en ai aucune idée). Pour être sûr, je conseillerais de faire les dynamic_cast<> pour des objets créés par une bibliothèque uniquement dans la bibliothèque en question.

Ou mieux, ne jamais faire de dynamic_cast<> : On peut souvent s'en passer.

Sous le forum Qt d'ici même, on m'a conseillé de toute façon de faire un dynamic_cast, ce que je pense avoir réussit puisque je n'ai pas de message d'erreur, bien que je ne puisse pas encore tester...

Donc tout reste à voir!
donc le transtypage dynamique diffère du transtypage type? Puis-je savoir en quoi? et pourquoi?

Principalement parce que tu as une vérification de ce qui est fait...

Code:

---

1 2 3 4 5 6 7 8

/* soit obj déclaré comme un pointeur sur un objet de type Mere  * mais pointant sur un objet quelconque de l'arbre d'héritage  */ Fille1* trans=dynamic_cast<Fille1*>(obj); //trans==NULL si transtypage échoue Fille1 transref=dynamic_cast<Fille&)(*obj); //lance std::bad_cast si transtypage échoue Fille2* trans2=static_cast<Fille2*>(obj);//aucune vérification... bobo en perspective Fille2 trans2ref=static_cast<Fille2&>(*obj);//aucune vérification... bobo en //perspective

---

et, bien sur, je ne parle pas du transtypage "C style" qui laisse faire réellement tout ce qu'on veut :P

Code:

---

1 2 3 4

Fille1 * pTrans = dynamic_cast<Fille1*>(pObj); //trans==NULL si transtypage échoue Fille1 &transref = dynamic_cast<Fille1&>(*pObj); //lance std::bad_cast si transtypage échoue Fille2 * pTrans2 = static_cast<Fille2*>(pObj); //aucune vérification... bobo en perspective Fille2 &trans2ref = static_cast<Fille2&>(*pObj); //aucune vérification... bobo en perspective

---

Ok, merci beaucoup pour vos informations!

ça me fait avancer dans mon apprentissage de la POO :)