Discussion :

[Seb des Monts]

Bonjour,

en vue d'éradiquer un petit problème de "Pure virtual function called" à l'exécution d'un programme, j'ai mis ça dans un moteur de recherche bien connu, et je suis tombé sur une info qui m'étonne un peu :

le destructeur des classe filles appellent naturellement le destructeur de la classe mère. le problème c'est qu'avec un Mere* pointant vers une instance de Fille, l'appel du destructeur (par delete) se contente par défaut d'appeler le destructeur de Mere (normal). il faut donc rajouter le mécanisme d'indirection virtuel pour que ça soit le destructeur du type réel de l'objet pointé qui soit appelé

Rassurez-moi, ceci est faux ? On peut bien faire :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
class A
{
   A(){}   
   virtual ~A(){}
};
 
class B : public A
{
   B(): A(){}
   virtual ~B(){}
};

Code :

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

vector<A*> Tab;

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
void NettoyerTab()
{
    int i =0, imax = Tab.size();
    for(i = 0; i < imax; ++i)
    {
        if(Tab[i]) != NULL)
        {
            delete ( Tab[i] );  
        }
    }
    Tab.clear();
}

Mon problème s'arrange en fait traquant les fonctions virtuelles pures dans les constructeurs et destructeurs.

Je ne pense pas qu'il soit nécessaire de transtyper pour bien deleter, même dans le cas cité.
Merci d'avance pour cette précision.

[JolyLoic]

C'est pour le moins imprécis. Déjà, "rajouter le mécanisme d'indirection virtuel" signifie juste dans le texte déclarer le destructeur de la classe de base "virtual". Mais ce qui se passe si ce n'est pas fait, ce n'est pas simplement que le mauvais destructeur sera appelé, c'est un comportement indéfini qui peut avoir d'autres impacts (corruption mémoire...).

Je ne vois pas de problèmes dans ton code.

[koala01]

Salut,

Visiblement, tu as mal lu ce qu'il dit:

Si le destructeur de la classe mère n'est pas virtuel, le fait d'invoquer delete sur un pointeur vers le type de la classe mère n'appellera effectivement pas le destructeur de la classe enfant.

Donc, ceci ne fonctionne pas:

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
 
class A
{
    public:
        A(){cout<<"constructeur de A"<<endl;}
        ~A(){cout<<"destructeur de A"<<endl;}
};
 
class B: public A
{
    public 
        B(){cout<<"constructeur de B"<<endl;}//s'il existe un constructeur
                               // par défaut pour la classe mère, son appel est
                               // implicite
        ~B(){cout<<"destructeur de B"<<endl;}
};
int main()
{
    std::vector<A*> tab;
    for(int i=0;i<10;++i)
        tab.push_back(new B);
    for(int i=0;i<10;++i)
        delete tab[i];
    return 0;
}

Pour que le polymorphisme fonctionne, il faut que le destructeur de A soit déclaré virtuel (ce qui fera en sorte que celui de B le soit également de manière implicite, même s'il est préférable de l'indiquer explicitement )

[Seb des Monts]

merci pour ces précisions.
koala, tu as raison. J'aurai pu le comprendre autrement.
Mais comme je ne vois pas de bonne raison pour ne pas avoir les destructeurs virtuels dans une hiérarchie de classes, ça m'a fait douter...
merci

[Médinoc]

Je ne vois pas de bonne raison pour ne pas avoir les destructeurs virtuels dans une hiérarchie de classes

Tout simplement quand elles ne sont pas dédiées à un emploi polymorphique.

GotW conseille d'avoir le destructeur de classe mère soit public et virtuel, soit protégé et non-virtuel (sachant qu'il conseille aussi de déclarer systématiquement les constructeurs de la classe mère comme protégés, et n'autoriser que l'instanciation des classes "feuilles").

[Seb des Monts]

ha oui !
C'est ça d'analyser par le prisme de ses projets !

[koala01]

Je me permet une légère digression sur le sujet (on scindera si nécessaire ), mais j'en viens presque à me demander si, dans de nombreux cas, on n'en arrive pas à envisager le polymporphisme comme tout à fait naturel, alors qu'il devrait être considéré, à l'instar des goto, de la récursivité et d'autres méthode, comme ne devant intervenir que lorsque c'est réellement nécessaire...

Comprenez moi, ce n'est pas son utilité que je remets en cause, mais son usage.

J'ai l'impression que l'on considère le polymorphisme comme aussi naturel que le fait de respirer ou d'avoir deux jambes, sans se rendre compte qu'il s'agit d'une technique qui représente malgré tout un cout non négligeable en terme de performances.

J'ai l'impression que, dans bien des cas, on gères des collections de pointeurs dont le type est déclaré comme étant la classe de base pour "profiter du polymorphisme", alors qu'il serait largement plus intéressant de gérer les différents types d'objets sous la forme d'autant de collections qu'il n'y a de types réels...

[Seb des Monts]

naturel... quand même pas ! Utiliser le polymorphisme nécessite généralement un petit effort de conception.
Et si on appliquait ta proposition, le code serait beaucoup moins simple et moins lisible.
Je trouve qu'avec les performances actuelles des machines, c'est dommage de privilégier encore la performance au détriment de la lisibilité / maintenabilité du code. Jusqu'à un certain point, évidemment...
Mais pour gérer des listes de lignes de commande, de pièces ou de services, par exemple, ce serait dommage de trop se compliquer la vie pour des petites listes d'objets relativement modestes. Le polymorphisme me semble hyper adapté pour ça, et si ça coûte un peu, c'est pas trop grave.
Les processeurs ont été multipliés par 3 ou 4 depuis le début du projet, et les besoins du projet (en terme de gestion de listes d'objets) n'ont guère changés

[koala01]

naturel... quand même pas ! Utiliser le polymorphisme nécessite généralement un petit effort de conception.

Oui, bien sur qu'il nécessite généralement un effort de conception...

Ce que je voulais dire, c'est que, bien souvent, la première idée qui vient à l'esprit lorsqu'il faut gérer une collection passe "naturellement" (dans le sens où c'est une des premières choses auxquelles on pense) passe par le polymorphisme

Et si on appliquait ta proposition, le code serait beaucoup moins simple et moins lisible.

j'aurais du préciser "polymorphisme dynamique"... Le bon, le dur, celui qui passe par l'héritage publique...

Avec les template par exemple, tu obtiens également une certaine forme de polymorphisme sans forcément rendre le code ni beaucoup moins simple, ni moins lisible...

Le tout en évitant l'écueil qui consiste à envisager l'héritage publique dans une situation dans laquelle il ne faudrait pas l'envisager en vertu du principe de subsitution de Liskov

Je trouve qu'avec les performances actuelles des machines, c'est dommage de privilégier encore la performance au détriment de la lisibilité / maintenabilité du code. Jusqu'à un certain point, évidemment...

Comme tu l'as dit "jusqu'à un certain point", et, "jusqu'à un certain point", je suis effectivement d'accord avec toi

Par contre, je ne suis vraiment pas intimement persuadé qu'il soit possible de faire un parallèle entre l'utilisation du polymorphisme et la lisibilité / maintenabilité du code.

Pour certains langages uni paradigmes, le parallèle est plus facile à faire, mais, en C++, la possibilité d'utiliser le paradigme de programmation générique rend ce parallèle beaucoup plus hasardeux

Mais pour gérer des listes de lignes de commande, de pièces ou de services, par exemple, ce serait dommage de trop se compliquer la vie pour des petites listes d'objets relativement modestes. Le polymorphisme me semble hyper adapté pour ça, et si ça coûte un peu, c'est pas trop grave.
Les processeurs ont été multipliés par 3 ou 4 depuis le début du projet, et les besoins du projet (en terme de gestion de listes d'objets) n'ont guère changés

Je me suis peut être mal exprimé, mais il y a une mauvaise compréhension de ce que je voulais dire...

Bien sur, je le répète, le polymorphisme "dynamique" est nécessaire / utile / intéressant.

Bien sur, si tu veux gérer en même temps des camions et des voitures, il faut les gérer comme étant de leur base commune qui est véhicule, je ne disconvient absolument pas de ce fait.

Par contre, là où il y a un problème, c'est quand, alors que l'on sait pertinemment que l'on va gérer une collection de "Voiture", on travaille avec une collection de "Vehicule* ", que Voiture et Vehicule soient effectivement polymorphes ou non, avec des transtypages dans tous les coins parce que l'on a, décidément, besoin de fonctions qui sont propres au type Voiture...

Dans de telles circonstances, nous flirtons très sérieusement avec le problème de conception

[screetch]

un cas typique d'emploi abusif de l'héritage : les bibliotheques de widget graphiques a 22 étages