Discussion :

[Somato]

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 :

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

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?

[screetch]

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 :

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

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 :

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
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

[Somato]

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?

[JolyLoic]

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.

[Somato]

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 :

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

virtual void doStuff() { };

donc ceci est-il nécessaire?

[Alp]

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

[koala01]

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:

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)

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

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 )

[Somato]

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

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):

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

[Alp]

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.

[koala01]

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 :

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
 
/* 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

[Somato]

Alors en gros:

Code :

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

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 :

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
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

[koala01]

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 :

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

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
}

[Médinoc]

Code C++ :

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

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 C++ :

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

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

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

[koala01]

Code C++ :

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

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 C++ :

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

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

[Médinoc]

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

[koala01]

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

[Somato]

Code :

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

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 :

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

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'
                                      }

[koala01]

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

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

[Somato]

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

[Médinoc]

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).