destructeur virtuel pur

Version imprimable

Voir 40 message(s) de cette discussion en une page

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

Voir 40 message(s) de cette discussion en une page