Classes abstraites sans méthode virtuelle pure

Hello,

Je souhaiterais faire une classe non instanciable.

Apparemment, la seule façon de faire ça, c'est de créer un méhode virtuelle pure, et de la concrétiser dans les classes filles.

Mais une fonction de même nom pour chacune des classes filles n'a pas de sens dans la hiérarchie de classe que je voudrais faire. Ce qu'elles ont en commun est déjà concrétisé dans la classe de base.

Cela signifie-t-il que je doive créer une fonction virtuelle pure bidon, que je concrétise par une fonction vide dans chacune des classes filles ?

Merci.

Tout dépend de ce que tu appelles "en commun". Est-ce le code ou le prototype des méthodes ?

Car si tu as du code différent dans chaque classe fille, mais qui soient stockés dans une même méthode (prototype identique), alors cette méthode est une bonne candidate au titre de méthode virtuelle pure.

Deux façons courantes :

- Constructeur(s) en accès protégé
- Destructeur virtuel pur (pas supporté par certains compilos grincheux)

Non, je n'ai pas de méthode d'un prototype donné qui est commun aux classes filles.

je comprend pas pourquoi il n y a pas de methode sspecialiées (dans tes classes filles) definit de manière communes dans la classe mère.

C est le propre du polymorphisme pourtant.

Je pense que les methodes unique aux classes filles devrait etre utilisé dans les redefinitions des methodes communes de la classe mère (methode virtuelles pures).

cependant il n est pas possible de creer un classe abstraite sans au moins une methode virtuelle pure...

Citation:

---

Envoyé par ZaaN

cependant il n est pas possible de creer un classe abstraite sans au moins une methode virtuelle pure...

---

Ca dépend de la définition de "abstraite" qu'on a. Celle qui semble être la bonne c'est "une classe non instanciable", donc dans ce cas les constructeurs protégés font l'affaire.

Citation:

---

Envoyé par Laurent Gomila

Ca dépend de la définition de "abstraite" qu'on a. Celle qui semble être la bonne c'est "une classe non instanciable", donc dans ce cas les constructeurs protégés font l'affaire.

---

Oui, c'est une super idée ça... Je note!
J'ai un peu le même problème, et ça peut rendre service.

Thanks ! :D

Les destructeurs protégés ont en effet l'air de convenir.

Merci.

Citation:

---

Envoyé par oodini

Les destructeurs protégés ont en effet l'air de convenir.

Merci.

---

Constructeur, pas destructeur ;)

Euh... oui...

Je me suis mélangé les saucisses dans ma réponse. :-)

Destructeur aussi.
Je suis géné par une classe mère avec rien de spécialisable. Du coup je pêche à voir où l'on subtitura quoique ce soit.

Citation:

---

Envoyé par Luc Hermitte

Destructeur aussi.

---

Pas s'il veut faire ça :

Code:

---

1 2	Base* b = new Derivee; delete b;

---

Citation:

---

Envoyé par Laurent Gomila

Pas s'il veut faire ça :

Code:

---

1 2	Base* b = new Derivee; delete b;

---

---

Dans ce cas le destructeur doit etre virtuel.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Dans ce cas le destructeur doit etre virtuel.

---

Aie aie aie ... :marteau:
Avec tout le respect que je te doit :ave:, ... de tout temps les développeurs C++ ont eu de graves déconvenues avec les destructeurs non virtuels (bannis par Stroustrup, c'est dire). Donc la question ne se pose même pas.

Encore que :

Citation:

---

Envoyé par [url=http://www.gotw.ca/publications/mill18.htm]GOTW : Virtuality[/URL]

Guideline #4: A base class destructor should be either public and virtual, or protected and nonvirtual.

---

Citation:

---

Dans ce cas le destructeur doit etre virtuel.

---

Bien sûr, là on parlait juste de l'accès protégé ou publique (enfin moi en tout cas... peut-être pas Luc).

Citation:

---

Guideline #4: A base class destructor should be either public and virtual, or protected and nonvirtual.

---

Je trouve que ça résume bien les choses.

Citation:

---

Envoyé par Laurent Gomila

Bien sûr, là on parlait juste de l'accès protégé ou publique (enfin moi en tout cas... peut-être pas Luc).

---

Tu appelais delete avec un pointeur vers la classe de base.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Tu appelais delete avec un pointeur vers la classe de base.

---

Pour illustrer le fait qu'il ne doit pas être en accès protégé. Qu'il doit être virtuel, ça je l'avais déjà dit avant.

Maintenant si tu te met à citer C/C++ Users Journal, tu pourras toujours trouver 2 articles qui parlent de la même chose et qui se contredisent ... pas une référence en soi.

Ce n'est pas feu le CUJ qui a été cité, mais Herb Sutter. On retrouve donc cette phrase dans le GOTW et dans son Coding Standards. L'auteur, la maison d'édition, et le titre du bouquin vont faire que cette "règle" risque de s'imposer.

Sinon, je parlais bien d'un destructeur protégé (et non-virtuel). Le fait qu'il n'ait aucune fonction virtuelle dans sa classe mère non instanciable me fait dire que :
- soit il part sur une classe agglomérat de données et autres fonctions qui sert de base à la définition d'autres classes (réutilisation de code) ; je ne vois pas de manipulation polymorphique des données
- soit il part pour faire des dynamic_cast dans tous les sens ; là il faut bien le destructeur virtuel, mais le design sens le moisi.

Il est vrai qu'il pourrait y avoir des cas intermédiaires, mais j'ai plus supposé que le design n'était pas moisi et de la première catégorie. Du coup, l'intérêt du destructeur public est vite faible. Mais bon.

Dans tous les cas seule la présence d'une fonction membre virtuelle-pure garantit la non-instanciabilité.

EDIT: grosse bétise dans le dernier paragraphe.

Désolé pour le non respect dut au monsieur ...

Je suis quand même demandeur de l'utilitée d'un destructeur non virtuel autre que vide et servant à émettre une erreur de compilation ...

Au fait, dans l'exemple de l'article, si j'ai bien tout lu, il aurait été plus propre de mettre l'operateur delete en protégé plutôt que le destructeur ...

Pas une question de respect. Juste une constatation : c'est un auteur influent. Et à l'exception de quelques trucs, ce qu'il écrit tend à faire force de loi -- comme avec les autres auteurs influents.


Un des intérets des destructeurs protégés non virtuels, c'est aussi pour les classes qui n'ont pas une sémantique d'entité. On définit des services qui seront importés par des classes filles qui vivent sur la pile. La classe mère n'est pas instanciable sur la pile. Du coup, protéger le delete n'empêche pas grand chose.
Mais il est vrai que l'on peut se contenter de mettre tous les constructeurs en protégé ou privé -- pour en revenir à la question de l'OP.

La question du destructeur protégé non-virtuel dans une classe de base vient de la dichotomie :
- soit on veut une destruction polymorphique -> public virtuel
- soit on ne la veut pas (ex. typique: les politiques) -> protégé non-virtuel

:arf:, po tout compris je crois que ca ira mieux le jour ou je se serait confronté au pb.
Pis c'est un sujet qui à fait coulé beaucoup d'encre les destructeurs non virtuels. On va pas partir dans un HS infini.