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