Discussion :

[Linu6]

Bonjour

J'ai besoin d'une précision sur les destructeurs virtuels

soit une classe de base abstraite telle que:

Code :

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

1
2
3
4
5
6
7
class Base
{
.........
public:
virtual ~Base()
....
};

et une deuxième classe dérivée normale telle que

Code :

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

1
2
3
4
5
6
7
class Derive: public Base
{
....
public:
~Derive();
...
};

ensuite supposons qu'on veuille créer un Derive en faisant:

Code :

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

1
2
3
 
Base *b;
b = new Derive(...);

Est qu'il est normal que les objets (Base et Derive) crées de cette sorte ne soient pas détruit à la fin de l'exécution?

.. parce que lors de l'exécution les messages affichés dans les constructeurs s'affiche sur l'écran, mais pas les messages contenus dans les destructeurs..

voila.

[Davidbrcz]

Dans ton code, la classe Base n'est pas abstraite. Elle n'a pas de fonction(s) virtuelle(s) pure(s).

Ensuite:

Est qu'il est normal que les objets (Base et Derive) crées de cette sorte ne soient pas détruit à la fin de l'exécution?

bah oui ! Avec new, tu dit au compilateur, "je vais gérer manuellement la mémoire", ce qui implique de détruire la variable avec delete.

[Linu6]

Tiens donc, c'est donc la fonction virtuelle pure qui rend la classe abstraite?

Mais pourtant je croyais que le destructeur virtuel seul suffisait pour rendre une classe abstraite, dans la mesure où il interdit son instanciation... non?

[Lucien63]

Tiens donc, c'est donc la fonction virtuelle pure qui rend la classe abstraite?

Tout à fait !

[Linu6]

Mais dans ce cas là alors, c'est quoi l'intérêt des destructeurs virtuel.. si ce n'est pas rendre une classe abstraite?

[Davidbrcz]

Si ta classe de base doit servir en tant qu'abstraction, le destructeur virtuel est utile car il va permettre d'appeler le bon destructeur lors du delete.

[mazipha]

Si tu rajoutes un delete b à ton code, tu verras que les 2 destructeurs sont appellés.
Si tu enleves le virtual du destructeur de la classe de base, seul le destructeur de la classe mère sera appelé.

C'est à celà que sert le virtual. C'est à dire à faire en sorte que le destructeur de la classe fille soit appelé, même dans le cas où ne possède qu'un pointeur de classe mère

[loufoque]

Si tu enleves le virtual du destructeur de la classe de base, seul le destructeur de la classe mère sera appelé.

Non. C'est un comportement indéfini.

[ac_wingless]

Le comportement est bien défini, la description de mazipha est correcte.

[nicroman]

De façon "simplifiée":
new = malloc() + appel du constructeur
delete = appel du destructeur + free()

Code :

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

1
2
3
 
Base* b;
b = new Derivee(); // malloc() + appel du constructeur de Derivee() (qui va commencer par appeler le constructeur de Base()).

Dans tous les cas... virtuelle ou non... Pour libérer la mémoire il manque donc un "delete"

Code :

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

1
2
 
delete b;

Le destructeur est comme n'importe quelle fonction...

Si le destructeur de base n'est pas virtuel... Appel du destructeur de b = simple appel à ~Base()

Si le destructeur de 'Base' est virtuel... Appel du destructeur de b = appel à la fonction correspondante de la table virtuelle de b. En l'occurence ~Derivee()... Qui va (à la fin) appeler ~Base()

[loufoque]

Le comportement est bien défini, la description de mazipha est correcte.

Ce n'est pas ce que dit le standard.
C'est bel et bien un comportement indéfini, ce qui est clair puisque les opérateurs new/delete peuvent se surcharger pour chaque type.

[ac_wingless]

Il faudrait alors informer rapidement Bjarne Stroustrup de ce point précis du standard , car il se permet d'écrire "Had Base's destructor not been virtual, Derived's destructor would not have been called" dans sa FAQ technique. C'est en effet logiquement équivalent au "Si tu enleves le virtual du destructeur de la classe de base, seul le destructeur de la classe mère sera appelé." de mazipha.

[Luc Hermitte]

Pour appuyer les dire de loufoque:

In the first alternative (delete object), if the static type of the operand is different from its dynamic type, the static type shall be a base class of the operand’s dynamic type and the static type shall have a virtual destructor or the behavior is undefined. In the second alternative (delete array) if the dynamic type of the object to be deleted differs from its static type, the behavior is undefined.

[koala01]

Salut,

Il faut déjà bien comprendre ce que signifie le terme "undefined behaviour", que l'on traduit très justement par "comportement indéfini"...

Il s'agit d'un comportement pour lequel la norme laisse le créateur du compilateur libre de choisir ce qui sera exécuté.

Concrètement, un tel comportement peut donc strictement tout faire: appeler le destructeur de la classe de base, celui de la classe dérivée ou... formater ton disque dur

L'expérience montre que de nombreux compilateurs vont gérer l'absence de destructeur virtuel de la même manière, mais ce n'est donc surement pas une raison pour en tirer une règle ferme et définitive

Ceci étant dit, revenons en au problème des classes abstraites...

Une classe est dite "abstraite" si elle dispose au minimum d'une méthode virtuelle pure.

Une méthode virtuelle pure est une méthode virtuelle pour laquelle on a prévenu le compilateur qu'il n'existe pas d'implémentation de la fonction.

Cela se fait en ajoutant = 0 à la fin de la déclaration (ex virtual void mafonc() = 0; )
Comme il n'est pas possible pour le compilateur de créer une instance d'objet si toutes les méthodes ne sont pas définies, une classe pour laquelle il restera une méthode non définie ne sera donc pas instanciable.

Ainsi, on pourrait tout à fait envisager une arborescence d'hértiage proche de

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
30
31
32
33
34
35
36
37
38
39
40
/* function1 et function2 sont virtuelle pures 
 * la classe AbstractBase est donc une classe abstraite
 */
class AbstractBase
{
    public:
        AbstractBase();
        virtual ~AbstractBase();
        virtual void function1() = 0;//virtuelle pure
        virtual void function2() = 0;//virtuelle pure
};
/* si la classe AbstractDerivee dispose des informations permettant
 * de fournir un comportement à function1 et qu'elle définit donc ce 
 * comportement mais qu'elle ne définit pas le comportement de 
 * function2, elle reste abstraite
 */
class AbstractDerivee : public AbstractBase
{
    public:
        AbstractDerivee();
        virtual ~AbstractDerivee();
        virtual void function1();
         /* function2 est toujours virtuelle pure ici
          */
};
/* il est possible de définir un comportement pour toute méthode virtuelle 
 * accessible... y compris les méthodes virtuelles des classe ancêtres
 * Le fait de définir (enfin) un comportement pour function2 fournira la
 * première classe instanciable
 */
class Derivee : public AbstractDerivee
{
    public :
        Derivee();
        virtual ~Derivee();
        virtual function2();
        /* rien n'empêche de redéfinir le comportement de function1... mais ce
         * n'est plus obligatoire ;)
         */
};

[mazipha]

L'expérience montre que de nombreux compilateurs vont gérer l'absence de destructeur virtuel de la même manière, mais ce n'est donc surement pas une raison pour en tirer une règle ferme et définitive

En théorie c'est tout à fait exact, le standard laisse le choix au compilateur, mais en pratique existe t'il un compilateur connu qui ne se comporte pas comme les autres sur ce point?

[Luc Hermitte]

Une destruction ne se résume pas uniquement à un appel au destructeur. Il y a aussi de la mémoire en jeu.