Discussion :

[Asmod_D]

Bonsoir,

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

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

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

  virtual ~BaseAliment()=0;

merci !

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

[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

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

[Laurent Gomila]

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

[Joel F]

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é

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

[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 !

[koala01]

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 :

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

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

[koala01]

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 :

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

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

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

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

[koala01]

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

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

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

[Laurent Gomila]

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

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.

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.

[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

[Flob90]

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.

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.

[Laurent Gomila]

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

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.

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 ?

[koala01]

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

[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 :

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

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.

[koala01]

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