destructeur virtuel pur

Version imprimable

Bonsoir,

dans quelle cas utilise t'on un destructeur virtuelle pure et pourquoi ?
j'ai un exemple de code :

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
class BaseAliment 
{
 protected:
    //les données de la classe de base
    double m_prix;
    std::string m_name;
 
        virtual ~BaseAliment()=0;
        BaseAliment(double prix=0,const std::string& name="");
 
 public:
 
    virtual double      GetPrix() const;
    virtual std::string GetName() const; 
 
    virtual void Afficher(std::ostream & flux) const;
};
 
class Aliment : public BaseAliment
{
 
public:
    Aliment(double prix=0,const std::string& name="");
    virtual ~Aliment();
};

Code:

virtual ~BaseAliment()=0;

merci !

30/08/2010, 00h06
zul

Le seul intérêt que je vois ici est de forcer la classe à devenir "abstraite" (cad elle ne peut pas être instanciée directement). Attention, il faut définir le destructeur, même si il est virtuel pur.
30/08/2010, 03h52
koala01

Salut,

Pour commencer, il faut peut être comprendre ce qu'est une fonction virtuelle pure.

Une fonction virtuelle est, tu le sais surement, une fonction au sujet de laquelle on prévient le compilateur que son comportement peut être modifié dans les classes dérivées.

Typiquement, une fonction virtuelle pure indique au compilateur que l'on n'est pas en mesure de définir un comportement adapté (pour la classe de base) pour une fonction qui peut être redéfinie dans les classes dérivées.

Le cas le plus fréquent est que la classe de base ne dispose simplement pas des données nécessaires en vue de fournir un comportement un tant soit peu cohérent.

Le résultat, et c'est là le point important en relation avec ta question, c'est que le compilateur -- qui a "horreur du vide" -- interdira la création d'une instance de toute classe présentant une fonction virtuelle pure, et veillera donc à ce que toutes les fonctions virtuelles pures soient définies dans les classes dérivées si l'on souhaite pouvoir en créer une instance.

On parle, pour les classes qui présentent au moins une fonction virtuelle pure, de classe abstraite, par opposition à des classes "concrètes" qui peuvent être instanciées ;)

Le fait est qu'il est parfois intéressant d'interdire la création d'une instance de la classe de base: Tu pourrais estimer (à très juste titre d'ailleurs) qu'il n'est pas opportun de créer une instance de la classe Vehicule, de manière à forcer toute instance de cette classe à être soit un Camion, soit une Voiture (ces deux classes héritant de Vehicule ;))

Seulement il arrive aussi que tu soit malgré tout en mesure de fournir un comportement de base pour l'ensemble des fonctions présentes dans la classe de base :aie:

Si tu veux, malgré tout, interdire la création d'une instance de celle-ci, la seule fonction que tu peux déclarer comme étant virtuelle pure sera... le destructeur.

NOTA: Tu devra, de toutes manières, implémenter le destructeur, tout simplement pour que les classes dérivées soient en mesure d'être détruites correctement ;)
30/08/2010, 08h23
Laurent Gomila

Ici je ne pense pas que ça ait grand intérêt, le constructeur protégé suffit à rendre la classe abstraite.
30/08/2010, 11h01
Joel F

Citation:

Envoyé par Laurent Gomila

Ici je ne pense pas que ça ait grand intérêt, le constructeur protégé suffit à rendre la classe abstraite.

euh non :€
abstraite = avec au moins une méhode virtuelle pure

le ctor protégé empeche juste la creation d'instance, c'ets décorrelé
30/08/2010, 11h17
JolyLoic

J'ai vu les deux définitions d'abstrait, y compris par exemple par Bjarne qui dans son dernier livre indique qu'une classe abstraite est une classe dont on ne peut pas créer d'instances.

J'avoue que cette définition n'est pas celle que j'aurais spontanément sortie, mais je ne la trouve pas si bête que ça.
30/08/2010, 12h01
poukill

Les deux définitions ne me choquent pas. Les principes sont différents, mais ça revient au même.
Ca me fait penser à l'agrégation comme héritage privé ou composition !

Tu as quand même deux restrictions avec le destructeur protégé et non virutel:

1- Pour interdire la création d'une instance de A, tu dois placer également son constructeur dans l'accessibilité protégée.

2- Si tu fais passer (sous la forme d'un pointeur) un objet de la classe dérivée comme étant un objet de la classe de base, tu ne pourra pas détruire ton objet parce que le destructeur est "protégé dans ce contexte".

Un exemple qui n'as pas d'autre intérêt que de montrer la réaction du compilateur:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 class A { public: A(){} protected: ~A(){} }; class B : public A { public: B(){} }; int main() { A a; // accepté, mais ne pourra être détruit A* ptr=new B; delete ptr; // ERROR : A::~A() is protected in this contexte return 0; }

30/08/2010, 15h01
Flob90

Une fonction virtuelle pure interdit complétement l'existance d'un objet de type dynamique A, alors qu'un constructeur protégé/privé non, ca fait quand même une sacré différence.

Citation:

Envoyé par Flob90

Une fonction virtuelle pure interdit complétement l'existance d'un objet de type dynamique A, alors qu'un constructeur protégé/privé non, ca fait quand même une sacré différence.

Exactement...

Tant que tu n'envisageras ton héritage que pour permettre une certaine forme de polymorphisme, comme, par exemple, pour passer un "objet passant pour être" du type de la classe de base à une fonction:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 void foo(A /*const*/ & a) { a.doSomething(); } int main() { /* on considère que B hérite de A, et que A a un constructeur et / ou * un destructeur protégé */ B b; foo(b); }
Cela passera.

Mais dés le moment où tu va utiliser un DP un temps soit peu évolué (fabrique, observateur, composite ou d'autres), ou que tu voudra, de manière générale, gérer la durée de vie d'un objet de type dérivé en le faisant passer pour un objet du type de base, tu n'aura plus le choix: tu devra utiliser un destructeur virtuel publique ;)

30/08/2010, 21h09
Laurent Gomila

Si la classe n'a aucun ami, je ne vois aucune façon d'instancier la classe si son seul constructeur est protégé. Donc a priori la classe donnée ici ne serait pas moins abstraite sans son destructeur virtuel pur.

Après le but n'est pas forcément de coller à la définition académique de "abstrait", mais de faire en sorte que seules les dérivées puissent construire la classe : et là le constructeur protégé est pile poil dans son rôle, le destructeur virtuel pur me paraissant de ce point de vue plutôt un "hack".
30/08/2010, 21h31
Flob90

Si il y a une fonction virtuelle pure, alors un objet ne pourra jamais être de type dynamique celui de la classe.

Si le constructeur est private (et pas d'amie), et qu'il n'y pas de fonction pour créer un objet, alros la classe ne sert à rien (si à offrir des membres statiques, mais c'est pas l'objectif d'une classe).

<Edit>Rien dit, j'avais omis un point du fonctionnement du langage</Edit>

Si le destructeur est protégé, rien ne m'empèche de le construire, le problème sera de la détruire. (donc en passant par un new sans delete ca compilera, même si c'est "sale", ou appeler delete juste pour désallouer la mémoire).

Mais je ne pense pas que destructeur virtuelle pure ou constructeur protégé soit plus un hack l'un que l'autre. La signification d'une fonction virtuelle pure est quand même bien : classe non instanciable, celui du constructeur protégé est, constructible uniquement pour faire une classe fille.

Edit: Pour ce qui est de la définition académique de "abstraite", je ne sais pas laquel est la bonne, ...
30/08/2010, 21h37
koala01

Citation:

Envoyé par Laurent Gomila

Si la classe n'a aucun ami, je ne vois aucune façon d'instancier la classe si son seul constructeur est protégé. Donc a priori la classe donnée ici ne serait pas moins abstraite sans son destructeur virtuel pur.

Après le but n'est pas forcément de coller à la définition académique de "abstrait", mais de faire en sorte que seules les dérivées puissent construire la classe : et là le constructeur protégé est pile poil dans son rôle, le destructeur virtuel pur me paraissant de ce point de vue plutôt un "hack".

Il ne faut pas oublier que toute instance créé sera aussi, tôt ou tard, détruite.

Tu peux, effectivement, empêcher la création d'une instance de la classe de base en plaçant le constructeur de celle-ci dans l'accessibilité protégée, ce qui rend effectivement la classe abstraite si l'on s'en tient à la définition "dont on ne peut créer d'instance".

Par contre, cela ne résout qu'une partie du problème: celui de la création de l'instance :P

Un destructeur protégé ne pourra, tout comme le constructeur, être appelé que par les classes dérivées.

Il y a donc toute une série de cas dans lesquels tu ne peux pas te contenter de placer un destructeur non virtuel protégé sans réfléchir d'avantage à la manière dont tu va gérer la durée de vie de tes objets, tels que ceux dans lesquels tu fais intervenir une fabrique ou, simplement, un composite :aie:

Dans tous ces cas où tout ce que tu as pour gérer la durée de vie des objets dérivés c'est un pointeur sur la classe de base, tu n'a absolument pas le choix: tu dois envisager un constructeur publique et virtuel.

Tant qu'à faire, autant s'assurer que la classe ne pourra réellement pas être instanciée, autant le rendre virtuel pur ;)
30/08/2010, 23h02
Laurent Gomila

Qui a parlé de destructeur protégé ? Pas moi en tout cas.

Citation:

Mais je ne pense pas que destructeur virtuelle pure ou constructeur protégé soit plus un hack l'un que l'autre. La signification d'une fonction virtuelle pure est quand même bien : classe non instanciable

Personnellement je ne mets pas une fonction virtuelle pure juste pour rendre la classe non instanciable, j'utilise ce mot-clé lorsque la fonction en question ne peut pas avoir d'implémentation dans la classe de base. Ce qui est contradictoire puisque le destructeur, pur ou non, devra quoiqu'il arrive être défini.

Citation:

Tant qu'à faire, autant s'assurer que la classe ne pourra réellement pas être instanciée, autant le rendre virtuel pur

Elle ne le peut déjà pas, alors à quoi bon ajouter un artifice inutile qui n'a pas de véritable intérêt conceptuel ?

En bref : je ne vois toujours pas ce que cela apporte dans l'exemple donné ici.
30/08/2010, 23h25
koala01

Le fait est que tu peux souhaiter qu'une classe soit considérée comme abstraite (comprend: qu'elle ne soit pas instanciable) malgré le fait que tu sois en mesure de fournir un comportement pour l'ensemble des fonctions qui la composent.

Si, de plus, tu souhaite gérer la durée de vie des objets qui en dérivent sous la forme (par exemple) d'un std::vector<Base*>, le seul moyen de t'assurer que l'ensemble des conditions soient respectées c'est... de recourir au destructeur virtuel pur, car c'est la seule fonction qui puisse à la fois être virtuelle pure et implémentée.

C'est, effectivement, contradictoire d'avoir une fonction virtuelle pure implémentée, mais il ne faut pas oublier que le destructeur en lui-même est déjà une fonction pour le moins particulière, à l'instar des constructeurs, dans le sens où ce sont les seules fonctions appelées automatiquement et qui ne présentent aucun type de retour, non :question:
30/08/2010, 23h32
Flob90

Citation:

Envoyé par koala01

Si, de plus, tu souhaite gérer la durée de vie des objets qui en dérivent sous la forme (par exemple) d'un std::vector<Base*>, le seul moyen de t'assurer que l'ensemble des conditions soient respectées c'est... de recourir au destructeur virtuel pur, car c'est la seule fonction qui puisse à la fois être virtuelle pure et implémentée.

virtuel tout court marche aussi bien. Je ne voit pas le lien direct entre le comportement à la suppresion, et l'interdiction de la création.

La seule différence que je vois entre les deux technique, c'est qu'on perd la possibilité d'avoir un constructeur non user-defined, chose qui définie certains comportements, mais c'est négligeable, AMA.

Citation:

C'est, effectivement, contradictoire d'avoir une fonction virtuelle pure implémentée

Je ne trouve pas ca contradictoire, une fonction virtuelle pure indique juste que juste l'interface doit être héritée, pas qu'il ne doit pas il y avoir un comportement par defaut utilisable explicitement.
30/08/2010, 23h36
Laurent Gomila

Je ne comprends toujours pas ce que tu essayes de m'expliquer.

Citation:

Le fait est que tu peux souhaiter qu'une classe soit considérée comme abstraite (comprend: qu'elle ne soit pas instanciable) malgré le fait que tu sois en mesure de fournir un comportement pour l'ensemble des fonctions qui la composent.

Dans ce cas j'ai déjà bien souvent un constructeur protégé, et si je n'en ai pas alors à choisir entre ajouter un constructeur vide protégé et rendre le destructeur virtuel pur, la première solution me paraît plus parlante conceptuellement. Mais là c'est une histoire de goût.

Citation:

Si, de plus, tu souhaite gérer la durée de vie des objets qui en dérivent sous la forme (par exemple) d'un std::vector<Base*>, le seul moyen de t'assurer que l'ensemble des conditions soient respectées c'est... de recourir au destructeur virtuel pur, car c'est la seule fonction qui puisse à la fois être virtuelle pure et implémentée.

En quoi la pureté du destructeur virtuel a-t-elle un rapport avec la gestion de la durée de vie des objets ?
30/08/2010, 23h45
koala01

Citation:

Envoyé par Flob90

virtuel tout court marche aussi bien. Je ne voit pas le lien direct entre le comportement à la suppresion, et l'interdiction de la création.

La seule différence que je vois entre les deux technique, c'est qu'on perd la possibilité d'avoir un constructeur trivial, chose qui définie certains comportements, mais c'est négligeable, AMA.

Je ne trouve pas ca contradictoire, une fonction virtuelle pure indique juste que juste l'interface doit être héritée, pas qu'il ne doit pas il y avoir un comportement par defaut utilisable explicitement.

Le fait est que, quelle que soient les conditions, le destructeur virtuel pur assure à lui-seul l'ensemble des conditions de non instanciabilité et de possibilité de destruction au travers de la classe de base:

Que tu aies un constructeur trivial ou non, publique ou non, que tu aies des fonctions virtuelles pour lesquelles tu es en mesure de fournir un comportement dans la classe de base ou non, le destructeur virtuel pur te donne toutes les garanties, nonobstant les autres situations ;)
30/08/2010, 23h53
Flob90
Oui, elle permet d'assurer les deux directement, mais la solution proposé par Laurent assure aussi les deux. Alors oui, 1 ca parait plus simple que 2, mais la différence de travail au moment d'écrire les classes n'est quand même pas flagrante au point d'invoquer un argument de simplicité :
Code:

1 2 3 4 5 6 7 struct A { virtual ~A() =0; }; A::~A() {} struct B { virtual ~B() {} protected: B() {} };
(7 caratères de plus écrit comme ca)

Au début je croyais qu'un constructeur en protected n'interdisait pas totalement la création, mais je me suis rendu compte que si. Du coup je ne voit pas trop les différence entre les deux méthodes, à part une pseudo-simplicité, et le fait que la seconde oblige de définir un constructeur.
30/08/2010, 23h53
koala01

Citation:

Envoyé par Laurent Gomila

Je ne comprends toujours pas ce que tu essayes de m'expliquer.

Dans ce cas j'ai déjà bien souvent un constructeur protégé, et si je n'en ai pas alors à choisir entre ajouter un constructeur vide protégé et rendre le destructeur virtuel pur, la première solution me paraît plus parlante conceptuellement. Mais là c'est une histoire de goût.

En quoi la pureté du destructeur virtuel a-t-elle un rapport avec la gestion de la durée de vie des objets ?

Nos réponses se sont croisées...

Tu dis que c'est une question de gouts entre rendre le fait de choisir d'ajouter un constructeur protégé et et celui de rendre le destructeur virtuel pur, et tu n'as pas tout à fait tord.

Mais, l'un dans l'autre, comme je l'ai dit dans ma réponse précédente, on se rend compte que le destructeur virtuel permet à lui seul d'assurer l'ensemble des besoins, quelles que soient les conditions ;)
31/08/2010, 00h04
koala01
Citation:
Envoyé par Flob90

Oui, elle permet d'assurer les deux directement, mais la solution proposé par Laurent assure aussi les deux. Alors oui, 1 ca parait plus simple que 2, mais la différence de travail au moment d'écrire les classes n'est quand même pas flagrante au point d'invoquer un argument de simplicité :

Code:

1 2 3 4 5 6 7 struct A { virtual ~A() =0; }; A::~A() {} struct B { virtual ~B() {} protected: B() {} };

(7 caratères de plus écrit comme ca)

Au début je croyais qu'un constructeur en protected n'interdisait pas totalement la création, mais je me suis rendu compte que si. Du coup je ne voit pas trop les différence entre les deux méthodes, à part une pseudo-simplicité, et le fait que la seconde oblige de définir un constructeur.
C'est surtout le fait que tu n'as pas besoin de t'inquiéter des autres conditions que ta classe de base doit respecter...

Si tu ne veux pas que ta classe de base soit instanciable, tu n'a qu'à déclarer le destructeur comme étant virtuel pur, et basta, même si une classe quelconque est déclarée amie de ta classe de base, même si tu veux garder un constructeur implémenté par le compilateur, même si tu n'a en réalité aucune fonction virtuelle autre (bon, d'accord, on pourrait se demander pourquoi faire hériter les autres classes de cette classe de base :D), même si quoi ou qu'est-ce, tu obtient toutes les garanties en un seul geste.

Je suis d'accord sur le fait que, comme le fait remarquer Laurent, cela na qu'un intérêt "purement conceptuel", mais son intérêt est, selon moi, des plus grands ;)
31/08/2010, 00h08
Flob90

Je fais aussi comme ca quand j'en ai besoin (c'est à dire pas souvent, ca arrive pas tout les jours de vouloir une classe non instaciable et qui n'a pas d'autre fonction virtuel à purifier), j'aurai cru qu'il y aurait un argument fort permettant de trancher, mais apparament non, une question de choix personnel donc.
31/08/2010, 00h44
koala01

Citation:

Envoyé par Flob90

Je fais aussi comme ca quand j'en ai besoin (c'est à dire pas souvent, ca arrive pas tout les jours de vouloir une classe non instaciable et qui n'a pas d'autre fonction virtuel à purifier), j'aurai cru qu'il y aurait un argument fort permettant de trancher, mais apparament non, une question de choix personnel donc.

C'est, très certainement, un choix personnel...

Il faut dire que c'est souvent le cas, dans bien des domaines en programmation / conception ;)

Mais je penses que c'est malgré tout la moins mauvaise solution dans le sens où elle permet de ne pas s'inquiéter des autres conditions: on ne veut pas que la classe soit instanciable, on déclare le destructeur comme virtuel pur, et on est sur que ce sera le cas, quelles que soient les autres situations ;)
31/08/2010, 01h14
Luc Hermitte
Citation:
Envoyé par Flob90

Code:

1 2 struct B { virtual ~B() {} protected: B() {} };
Code:

1 2 3 struct C : B { static B* f() { return new B(); } };
Seule une classe abstraite est non instanciable, seule une fonction virtuelle pure l'assure. Dans le cas où la pureté n'a de sens nulle part, il reste le destructeur pour lequel il est acceptable d'avoir cet étrange côté, pur mais implémenté (c'est possible avec toute fonction)

Ca me rappelle ça: http://groups.google.fr/group/fr.com...1b9f2ec843d93f
31/08/2010, 01h22
Flob90

@Luc: J'ai pensé à ca (c'est ce que j'avais en tête avant de faire un edit dans ma première réponse à Laurent), mais ca ne compile pas. (erreur, B est protégé dans ce contexte). D'ou la conclusion que les deux solutions fonctionnent.
31/08/2010, 01h41
Luc Hermitte

En effet. J'étais passé à côté de ce détail. Il faut vraiment rester dans B pour que cela marche -- ou alors un "#define protected public" avant l'inclusion de A.h pour passer outre, mais bon...
31/08/2010, 08h17
Aleph69

Bonjour,

il me semble qu'on utilise un destructeur virtuel pur lorsqu'on veut rendre une classe abstraite (non instanciable) alors qu'on ne souhaite pas imposer l'implémentation d'autres fonctions membres aux classes qui vont en dériver.

Les destructeurs virtuels purs sont les seules fonctions membres pures qui doivent être définies. Une conséquence directe de cela est que si la classe en question possède au moins une fonction membre virtuelle pure, alors son destructeur n'a pas besoin d'être pur.

En résumé, normalement, on ne trouve des destructeurs virtuels purs que dans les classes abstraites ne possédant aucune autre fonction membre virtuelle pure.
31/08/2010, 11h56
Asmod_D

merci à vous tous pour vos réponses.

donc si j'ai bien compris :

si on veut pas instancier une classe concrète" n'ayant pas de méthode abstraite" on doit créer un destructeur virtuelle pure .
31/08/2010, 12h02
Luc Hermitte

Mauvais vocabulaire à divers niveaux
Une classe concrète est instanciable.
Une classe abstraite est non instanciable.
Une classe est dite abstraite dès qu'elle possède une fonction virtuelle pure.
Quand aucune fonction n'a de sens à être pure, on peut jouer avec le destructeur tant que l'on n'oublie pas de le définir.

PS: il est des définitions de "méthode" qui disent "fonction virtuelle" -- c'est un terme impropre au C++.
31/08/2010, 13h19
Aleph69

Citation:

Envoyé par Asmod_D

donc si j'ai bien compris :

si on veut pas instancier une classe concrète" n'ayant pas de méthode abstraite" on doit créer un destructeur virtuelle pure .

Tu as un sérieux problème avec l'algèbre de Boole...
31/08/2010, 13h24
Flob90

Si tu ne veus pas d'instance, tu n'as qu'à pas en créer. Si tu ne veut pas pourvoir créer d'instance, là il te faut une classe abstraite ou un constructeur en protégé.
31/08/2010, 18h11
Asmod_D

désolé pour mes fautes d'expression
merci pour vos réponse !

Fuseau horaire GMT +2. Il est actuellement 02h01.