héritage et destructeurs virtuels.

Bonjour,

J'essaye de comprendre le fonctionnement de destructeurs virtuels.
Si on considère une classe de base et une classe héritée de cette classe, alors il risque d'y avoir des problèmes si il n'y a pas de destructeurs virtuels.
Je suis d'accord, cela semble logique.

J'ai décidé de mettre en application ce qui est écrit, avec l'héritage suivant.

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 26 27 28 29 30 31 32 33 34 35 36

class TimeKepper{ private: int o; public: TimeKepper(int u):o(u){}; ~TimeKepper(); }; TimeKepper::~TimeKepper(){ cout<<"~TimeKepper()"; }   class AtomicClock:public TimeKepper{ public: int k; public: AtomicClock(int i,int j):TimeKepper(i),k(j){}; static AtomicClock* getAtomicClock(); ~AtomicClock(){ cout<<"ee"; }; };   void main(){     int *o; AtomicClock *pta=new AtomicClock(9,8); { TimeKepper *ptkk=0; o=&(pta->k); ptkk=pta;   delete ptkk; } }

---

Normalement, ptkk ne devrait prendre en compte que la partie de base de l'objet pointé par pta.

Quand on fait delete ptkk, celui-ci ne devrait détruire que la partie de base de l'objet pointé par pta, laissant dans la mémoire la partie héritée. Ce qui fait que l'on pourrait toujours avoir la valeur 8 via *o. Or, ceci n'est pas le cas, car malgré l'absence de destructeurs virtuels, on ne peut plus lire la valeur de *o après la destruction. Qu'il y ait destructeur virtuel ou non, cela ne change rien. Je ne comprends pas pq.


(c'est pourtant exactement ce que fait scott meyers dans son livre pour
illustrer ce risque).


j'ai fait cela car je m'attendais, dans la mémoire, à ne trouver que 00 00 08, et pas 00 00 09 00 00 08 après le passage de delete

Merci

voila d'ailleurs ce que dit scott meyers:


There are lots of ways to keep track of time, so it would be reasonable to create a TimeKeeper base class along with derived classes for different approaches to timekeeping:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

class TimeKeeper {   public:   TimeKeeper();   ~TimeKeeper();   ...   }; class AtomicClock: public TimeKeeper { ... }; class WaterClock: public TimeKeeper { ... }; class WristWatch: public TimeKeeper { ... };

---

Many clients will want access to the time without worrying about the details of how it's calculated, so a factory function — a function that returns a base class pointer to a newly-created derived class object — can be used to return a pointer to a timekeeping object:

Code:

---

1 2 3 4 5

TimeKeeper* getTimeKeeper(); // returns a pointer to a dynamic-   // ally allocated object of a class   // derived from TimeKeeper

---

In keeping with the conventions of factory functions, the objects returned by getTimeKeeper are on the heap, so to avoid leaking memory and other resources, it's important that each returned object be properly deleted:

Code:

---

1 2 3 4

TimeKeeper *ptk = getTimeKeeper(); // get dynamically allocated object // from TimeKeeper hierarchy .. // use it delete ptk; // release it to avoid resource leak

---

. If getTimeKeeper were to return a pointer to an AtomicClock object, the AtomicClock part of the object (i.e., the data members declared in the AtomicClock class) would probably not be destroyed, nor would the AtomicClock destructor run. However, the base class part (i.e., the TimeKeeper part) typically would be destroyed, thus leading to a curious "partially destroyed" object. This is an excellent way to leak resources, corrupt data structures, and spend a lot of time with a debugger.

Ton programme présente un comportement indéterminé car le destruteur de TimeKepper n'est pas virtuel.

Ne cherche donc pas à déduire une loi générale, tu ne peux pas ^^ .
Tu peux tomber sur le cas de l'objet à moitié détruit, mais pourquoi de celui de l'objet totalement détruit, tu ne peux pas prévoir.

Citation:

---

Ton programme présente un comportement indéterminé car le destruteur de TimeKepper n'est pas virtuel.

---

je sais bien. C'est justement ce que j'ai envie de faire. Mais dois-je en déduire que, bien que cela ne puisse pas se voir, il y a comportement indéterminé car il n'y a pas de destructeur virtuel.

Dès qu'une classe est héritée d'une autre classe ==> destructeur virtuel??

Citation:

---

je sais bien. C'est justement ce que j'ai envie de faire. Mais dois-je en déduire que, bien que cela ne puisse pas se voir, il y a comportement indéterminé car il n'y a pas de destructeur virtuel.

---

Oui, c'est précisé dans la norme.

Citation:

---

Dès qu'une classe est héritée d'une PUBLIQUEMENT autre classe ==> destructeur virtuel??

---

Oui. La FAQ contient une entré là dessus.

Dans les cas des autres héritages, on peut pas upcaster (faire passer un objet de type dérivé pour un objet de type base, le problème, ne se pose donc pas)

Ou si il est non virtuel alors protected...

un destructeur protected??
ca existe ca?

Un bout de code étant toujours plus clair :

Code:

---

1 2 3 4 5 6

struct C { protected : ~C(); }

---

Salut,

Citation:

---

Envoyé par deubelte

un destructeur protected??
ca existe ca?

---

Oui, cela existe...

C'est à utiliser si:

• Tu veux qu'une classe dérivée hérite (publiquement) de la classe pour laquelle tu définis ton destructeur en protégé (mais non virtuelle)
• tu prévois d'interdire la destruction des objets dérivés lorsqu'il passent pour être des objet de la classe de base.

Lorsque le destructeur d'une classe de base est protégé, celui de la classe dérivée peut y accéder (parce que les éléments protégés de la classe de base sont accessibles depuis les fonctions de la classe dérivée), par contre, il t'est impossible d'invoquer la destruction depuis un pointeur ou une référence sur le type de base, car seuls les membres et les fonctions publiques sont accessibles "depuis l'extérieur de la classe".

De plus, si tu décides de définir le destructeur comme membre protégé, il y a de fortes chances que tu doives également définir le constructeur comme membre protégé également: Il serait en effet risqué de permettre la construction d'un objet... que l'on ne pourrait pas détruire :aie:

Ainsi, avec deux classes proches de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

class Base { /*blabla */ protected: /* le destructeur protégé est accessible depuis Derivee   * (et sera atomatiquement appelé depuis le destructeur   * cette dernière   */ ~Base(){} }; class Derivee : public Base { /* si on ne met rien, le destructeur est, par défaut,   * non inline et non virtuel :D   */ };

---

tu arrives à une situation proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

int main() { Derivee d; /* aucun problème */ Base b; /* DANGER: le constructeur de Base est accessible   * depuis l'extérieur, et l'on peut donc déclarer une variable   * de type Base   */ Base *ptrD = new Derivee; /* CRAC...*/ Base * p2=&d; /* aucun problème ici :D*/ /*...*/ delete ptrD; /* BOUM : ~Base est protégé dans ce contexte */ delete p2; /*surtout pas : p2 n'a pas été créé avec new */ } /* 1- Destruction de d : pas de problème   * 2- tentative de destruction de b : BOUM : ~Base est protégé   */

---

Il est à noter qu'il est même possible de définir un constructeur et un destructeur comme membres privés, par exemple, pour créer un singleton (faut-il te remettre en garde contre cet anti-pattern :question:), mais que, à ce moment là, il faudra prévoir une fonction membre statique publique capable d'appeler le constructeur, et, vraisemblablement une fonction membre statique publique pour le détruire (dépendant de la manière dont tu implémente le singleton) ;)

Citation:

---

Envoyé par deubelte

un destructeur protected??
ca existe ca?

---

La visibilité publique, protégée ou privée d'une fonction détermine juste dans quel contexte son appel sera autorisé ou non par le compilateur. N'importe quelle fonction peut avoir n'importe quelle des trois visibilités selon le sens que l'on souhaite lui donner.

Quand à ta question initiale, outre le problème du virtuel, je ne comprend pas très bien ton test. Ton destructeur ne fait qu'une écriture sur la sortie et tu ne sais rien (parce que le langage ne te dit rien, il s'agit d'un détail d'implémentation de ton gestionnaire de mémoire (os+compilo)) des conséquences de delete. Donc en quoi l'image mémoire de ton objet peut-elle t'informer de ce qui se passe ?

en fait, je ne comprends pas vraiment la gestion de la mémoire.
J'ai un cas très simple, que je ne comprends pas:

Quand je fais:

Code:

---

1 2 3 4 5

int main(){ {int o=3; } int p=4; }

---

alors si je me place à l'adresse mémoire &o, on a :

0x001AFDBE  cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌÌ
0x001AFDD4  03 00 00 00 cc cc cc cc 2c fe 1a 00 ef 16 90 00 01 00 00 00 78 14  ....ÌÌÌÌ,þ..ï.......x.
0x001AFDEA  89 00 a0 1b 89 00 ee 6b 26 73 00 00 00 00 00 00 00 00 00 b0 fd 7f  ..*...îk&s.........°ý.
0x001AFE00  64 7a da 00 00 00 00 00 00 00 00 00 00 00 1b 00 00 00 00 00 f0 fd  dzÚ.................ðý
0x001AFE16  1a 00 26 00 00 00 70 fe 1a 00 69 10 90 00 82 f9 ac 73 00 00 00 00  ..&...pþ..i....ù¬s....
0x001AFE2C  34 fe 1a 00 1f 15 90 00 40 fe 1a 00 33 38 21 76 00 b0 fd 7f 80 fe  4þ......@þ..38!v.°ý.€þ

on voit bien la présence de 03, au début de la deuxième ligne, (qui correspond à l'adresse de o). Quand on quitte la portée intérieure, je m'attendais à ce que la variable o soit supprimée. Or, on voit toujours le 03 au début de la ligne. Malgré cela, on a toujours la présence du 03.
Ainsi, après avoir passé la ligne p=4, on a:

04 00 00 00 cc cc cc cc cc cc cc cc 03 00 00 00

La variable prend de l'espace mémoire dans la fonction dans le sens où... il faut bien pouvoir en représenter la valeur :P

Ce qui se passe, c'est que la variable devient inaccessible une fois que l'on atteint l'accolade fermante, par contre, comment voudrait tu supprimer "physiquement" une variable d'une série d'instructions qui... ne sera plus modifié :question:

Soit la variable existe dans le code binaire, et elle peut, dans la portée où elle est accessible, être utilisée pour y placer une valeur, soit la variable n'existe pas dans le code binaire, et on ne peut simplement pas l'employer...

Enfin, ce n'est pas sur l'utilisation d'un simple type primitif que tu dois baser ton observation, mais plutôt sur une classe, de manière à observer que le destructeur est appelé au moment où l'on quitte la portée de la variable (et encore: il est préférable d'observer cela en assembleur, car, dans le code binaire, tu auras du mal à remarquer l'appel :P)

Citation:

---

Enfin, ce n'est pas sur l'utilisation d'un simple type primitif que tu dois baser ton observation, mais plutôt sur une classe, de manière à observer que le destructeur est appelé au moment où l'on quitte la portée de la variable

---

C'est ce que j'ai fait. J'ai testé avec une classe dans le cas d'allocations dynamiques, avec new, et quand on appelle le destructeur dans ce destructeur l'opérateur delete. Dans ce cas, on voit bien l'objet disparaitre.

Mais dans le cas d'allocation statique, l'objet reste dans la mémoire.

Citation:

---

comment voudrait tu supprimer "physiquement" une variable d'une série d'instructions qui... ne sera plus modifié

---

N'est ce pas ce qui se passe avec new/delete?

Ce que devient la mémoire après sa libération qu'elle soit explicite (delete) ou implicite (variable sur la pile) ne relève pas du C++ mais du système. Si ce sujet t'intéresse, c'est du côté système que tu dois regarder comment c'est gérer.

Citation:

---

Si ce sujet t'intéresse, c'est du côté système que tu dois regarder comment c'est gérer.

---

oui ca m'intéresse. Je pense que la gestion de la ressource mémoire est très importante pour un développeur. J'ai windows vista. Mais où chercher de la doc dans ce domaine?

Citation:

---

Envoyé par deubelte

oui ca m'intéresse. Je pense que la gestion de la ressource mémoire est très importante pour un développeur.

---

Jusqu'à un certain point uniquement...

Oui, tu dois gérer ta mémoire "aussi finement" que possible en veillant à libérer la mémoire de ce qui est devenu inutiles "en temps opportun", mais, passé un certain point, tu sera bloqué par les mécanismes de l'OS, et tu pourra dancer sur ta tête, tu ne pourra plus influer sur la manière dont ces mécanismes fonctionnent effectivement.

Ton role à toi, en tant que développeur, c'est:

• de ne pas prévoir 150 000 éléments dans un tableau si... 15 suffisent
• de veiller à libérer correctement tes ressources quand elles deviennent inutiles
• de choisir les structures adaptées à l'utilisation que tu fait de tes données / collections
• de fournir une logique aussi bonne que possible

Si, déjà, tu remplis ces quatre points, ton développement sera bon ;)

Et dans le cas ou ne définie pas de destructeur (c'est le compilateur qui le génère), ca va aussi poser problème???

En pratique on s'en sert pourquoi du destructeur protégé ?

Citation:

---

Envoyé par guillaume07

En pratique on s'en sert pourquoi du destructeur protégé ?

---

Justement, quand tu envisage une relation EST-UN, mais que tu ne devra jamais utiliser de la destruction polymorphe...

Tu va donc utiliser tes classes dérivées en tant que telles et non en les faisant passer pour des objet du type de la classe de base.

oui exact! merci