Destructeur de classe - remise à NULL

Bonjour,

J'ai créé une classe d'objet.

Ces objets appartiennent à un conteneur.

Celui-ci ne sait pas forcement à l'avance si un de ses objet est déjà créé. Par exemple, si on demande d'ouvrir un objet, le conteneur verifie si il existe :

- si il existe, il l'ouvre
- sinon il le crée puis il l'ouvre

Donc pour savoir si un objet est déjà créé, lors de la création du conteneur, j'initialise la liste de pointeurs vers ses objets à NULL, comme ça je peux tester :

Code:

---

1 2 3 4 5 6 7

ouvrirObjet(*pObjet) { if (pObjet == NULL) pObjet = new cObjet(); pObjet->ouvrir(); }

---

Sauf que lorsque l'on detruit un objet avec delete, le pointeur vers cet objet ne revient pas à NULL...

Donc ma question : est-il possible de mettre ce pointeur à NULL à l'intérieur du destructeur ?

Un truc du genre this = NULL; mais en plus fin, puisque ça c'est interdit....

Merci !

Citation:

---

Donc ma question : est-il possible de mettre ce pointeur à NULL à l'intérieur du destructeur ?

---

Non, mais rien ne t'empêche de le faire juste après le delete.

Ah !

Evidemment, j'oubliais de preciser, le delete est automatique...

J'ai une procedure fermerObjet() qui peut etre appelée depuis l'objet lui-meme et qui à la fin fait execute :

delete this;

Donc lors de l'execution du destructeur, je ne connait pas le pointeur vers l'objet.

Du coup je pensais à une astuce du genre :

- à la construction, stocker un pointeur vers le pointeur de l'objet (!!!!)
- à la destruction, mettre la valeur pointée par ce pointeur à NULL

C'est un peu tordu, et ça n'a pas vraiement marché (je m'y suis peut-etre mal pris)

Ca devient un peu bourrin là ;)

Tu pourrais détailler un peu plus ce que tu cherches à faire ? Je suis sûr qu'on peut trouver une solution plus élégante.

Ouais, je vais essayer d'etre plus clair :

J'ai un conteneur, qui contient 4 objets (par exemple)

du genre :

Code:

---

1 2 3 4 5 6 7

cConteneur { cObjet *pObjet1; cObjet *pObjet2; cObjet *pObjet3; cObjet *pObjet4; }

---

Le constructeur : (aucun objet n'existe)

Code:

---

1 2 3 4 5 6 7 8

cConteneur::cConteneur() { pObjet1 = NULL; pObjet2 = NULL; pObjet3 = NULL; pObjet4 = NULL; }

---

Le destructeur :

Code:

---

1 2 3 4 5 6 7

cConteneur::~cConteneur() { if (pObjet1 != NULL) delete pObjet1; if (pObjet2 != NULL) delete pObjet2; if (pObjet3 != NULL) delete pObjet3; if (pObjet4 != NULL) delete pObjet4; }

---

Ouvrir un objet :

Code:

---

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

cConteneur::ouvrirObjet(uneCondition) { switch (condition) { case condition_1 : if (pObjet1 == NULL) pObjet1 = new cObjet(); pObjet1->ouvrir(); break; case condition_2 : if (pObjet2 == NULL) pObjet2 = new cObjet(); pObjet2->ouvrir(); break; etc ...... } }

---

Et dans cObjet : (cette méthode est appelée sous certaines conditions : fin du traitement...)

Code:

---

1 2 3 4 5

cObjet::fermer() { fermerDesTrucs(); delete this; }

---

Donc mon probleme, c'est que si le conteneur ouvre un objet et que celui-ci s'est fermé (+ détruit) tout seul, le conteneur n'est pas au courant qu'il doit le ré-créer avant de le ré-ouvrir.....

Et pour d'autres raisons, je voudrait éviter de stocker un pointeur vers le conteneur dans chaque objet (les objets peuvent changer de conteneur etc...)

Donc mon vrai probleme, c'est de tester l'existence d'un objet via son pointeur....

Tu as une architecture pas facile à gérer, où la responsabilité des ressources est partagée entre le conteneur et la ressource elle-même. Un truc qui aiderait bien serait les pointeurs intelligents à base de comptage de référence, ça éviterait déjà d'avoir à gérer des dépendances partout. Avec boost::weak_ptr je crois même que tu peux être notifié lorsque le boost::shared_ptr lié est détruit, ce qui pourrait convenir dans ton cas.

Bien sûr la solution la plus simple serait qu'une seule classe ait la responsabilité entière des ressources, mais apparemment ce n'est pas possible dans ton cas.

PS : delete NULL est tout à fait valide, pas besoin de tester le pointeur.

Citation:

---

Avec boost::weak_ptr je crois même que tu peux être notifié lorsque le boost::shared_ptr lié est détruit, ce qui pourrait convenir dans ton cas.

---

Pour être exact, suivant la méthode utilisée pour accéder à l'objet via un weak_ptr (construction de shared_ptr avec passage de paramètre du weak_ptr, ou utilisation de la fonction weak_ptr::lock), tu auras une exception (bad_weak_ptr) ou un pointeur nul (shared_ptr::get() == 0) lors de la tentative d'accès à l'objet déjà détruit.

pourquoi tu fais pas une fonction qui ferai à peu près ça :

Code:

---

1 2 3 4 5 6

CContainer::liberer(*Objet) { Objet->fermer(); Objet = NULL; }

---

non ? :mouarf:

:lahola:
- Hé dis t'as vu Travail quelque part ?
- Non, moi je suis en vacances...

Merci, je vais regarder du coté de boost....


@Startux :

Si si, je fais ça aussi, mais dans le cas où c'est le conteneur qui détruit l'objet.
Et dans ce cas, pas de soucis.

Mon soucis, c'est lorsque l'objet se détruit lui-même !

(comme dans les films, une fois que l'ordinateur central a déclenché l'auto-destruction du vaisseau, tout le monde est dans la merde !!)

Citation:

---

Envoyé par buzzkaido

Code:

---

1 2 3 4 5

cObjet::fermer() { fermerDesTrucs(); delete this; }

---

---

Ca me parait vraiment bizzare, un objet qui appelle son propre destructeur...
En particulier, l'objet existe encore juste après puisqu'on est dans une de ses méthodes.

Citation:

---

Envoyé par Ulmo

Ca me parait vraiment bizzare, un objet qui appelle son propre destructeur...
En particulier, l'objet existe encore juste après puisqu'on est dans une de ses méthodes.

---

Il arrive qu'on ait besoin que des objets s'auto-détruisent, notamment lorsqu'ils sont les seuls à savoir quand le faire. Tant qu'il n'y a aucune référence à une fonction ou une variable membre après la destruction, rien n'empêche de la faire de cette manière.

Salut,

Ceci dit, pourquoi ne pas déléguer la destruction de l'objet au conteneur, et non à l'objet:question:

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 37 38 39 40 41 42 43 44 45 46 47 48 49

class cConteneur { cObjet *pObjet1; cObjet *pObjet2; cObjet *pObjet3; cObjet *pObjet4; public: void Detruire(cObjet* obj); //variante void Detruire(unsigned int ind); }; void cConteneur::Detruire(cObjet* obj) { // profitons de ce que obj dispose encore de l'adresse // vers laquelle il pointait apres sa destruction pour s'éviter quelques //lignes de code (il est paresseux, le koala :P:S) delete obj; if(obj==pOjet1) pObjet1=NULL; if(obj==pOjet2) pObjet1=NULL; if(obj==pOjet3) pObjet1=NULL; if(obj==pOjet4) pObjet1=NULL; } void cConteneur::Detruire(unsigned int ind); { switch(ind) { case 1: delete pObjet1; pObjet1=NULL; break; case 2: delete pObjet2; pObjet2=NULL; break; case 3: delete pObjet3; pObjet3=NULL; break; case 4: delete pObjet4; pObjet4=NULL; break; } }

---

D'autant plus que, tu semble malgré tout te contredire quelque peu:

Tu semble dire qu'à l'ouverture, l'objet peut éventuellement etre préexistant, mais qu'il devrait d'office etre détruit à la fermeture...

Alors, la question à cinq cents: comment l'objet pourrait il etre préexistant:question: (ou alors, il y a du code qui manque :P)

Citation:

---

Envoyé par Laurent Gomila

Il arrive qu'on ait besoin que des objets s'auto-détruisent, notamment lorsqu'ils sont les seuls à savoir quand le faire. Tant qu'il n'y a aucune référence à une fonction ou une variable membre après la destruction, rien n'empêche de la faire de cette manière.

---

N'est-il pas préférable d'utiliser une méthode ::destroy() qui fasse le ménage, et de l'appeler depuis le destructeur (sans effet si le ménage est déjà fait) ?

En fait je ne vois pas pourquoi l'objet serait seul à savoir quand se détruire. Il est détruit quand il sort de la portée où il a été créé, non ?

Citation:

---

Ceci dit, pourquoi ne pas déléguer la destruction de l'objet au conteneur, et non à l'objet

---

Apparemment l'objet peut changer de conteneur en cours de route, ce n'est donc pas ce dernier qui doit gérer la durée de vie de l'objet.

Citation:

---

N'est-il pas préférable d'utiliser une méthode ::destroy() qui fasse le ménage, et de l'appeler depuis le destructeur (sans effet si le ménage est déjà fait) ?

---

Et le destructeur, qui l'appelle ?

Citation:

---

En fait je ne vois pas pourquoi l'objet serait seul à savoir quand se détruire. Il est détruit quand il sort de la portée où il a été créé, non ?

---

On parle bien sûr d'instances allouées dynamiquement... Parce que "delete this" sur une instance locale à une portée, ça ne ferait pas exactement ce qu'on veut ;)

Citation:

---

Envoyé par Ulmo

En fait je ne vois pas pourquoi l'objet serait seul à savoir quand se détruire. Il est détruit quand il sort de la portée où il a été créé, non ?

---

Pas quand il a été créé avec new...

Le but des pointeurs est, justement, de permettre la persistance de l'objet en dehors de la portée où il a été créé, mais nécessite qu'un systeme quelconque soit mis en place pour retrouver l'adresse à laquelle se trouve l'objet ;)

En fait, soyons clairs: la variable de type pointeur est, effectivement, détruite quand on sort de portée, mais l'objet pointé par le pointeur continue, lui, à exister ;)

Ouioui, il y a des choses qui survivent à la portée.

Mais celui qui appelle la méthode qui détruira l'objet pourrait aussi bien le détruire lui même. C'est à dire remplacer :

Code:

---

1 2 3 4 5 6 7

cObjet::fermer() { fermerDesTrucs(); delete this; } ... UnCObjet->fermer();

---

par:

Code:

---

1 2 3 4 5 6

cObjet::~cObjet() { fermerDesTrucs(); } ... delete UnCObjet;

---

La sule différence que j'y voit est le nom de la fonction qui est peut-être moins clair.

Citation:

---

Envoyé par Laurent Gomila

Apparemment l'objet peut changer de conteneur en cours de route, ce n'est donc pas ce dernier qui doit gérer la durée de vie de l'objet.
(snip)

---

Si tel est le cas,comme on peut envisager que tous les conteneurs fonctionnent relativement de la meme facon, il suffit, quand le pointeur change de conteneur, de mettre le pointeur dans le conteneur d'origine à null, sans passer par Detruire ;)

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 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51

// renvoie le pointeur et le supprime du conteneur cObjet* cConeteur:zerote(unsigned int ind) { cObjet* temp=NULL; switch(ind) { case 1: temp=pObjet1; pObjet1=NULL; break; case 2: temp=pObjet2; pObjet2=NULL; break; case 3: temp=pObjet3; pObjet3=NULL; break; case 4: temp=pObjet4; pObjet4=NULL; break; } return temp; } //place un objet dans le conteneur à la place ind void cConteneur::Place(cObjet* obj, unsigned int ind) { /* il sera vraissemblablement utile de vérifier s'il ne faut pas   détruire l'objet avant de placer le nouveau ;)   ou, au minimum, un test de faisabilité ;) */ switch(ind) { case 1: pObjet1=obj; break; case 2: pObjet2=obj; break; case 3: pObjet3=obj; break; case 4: pObjet4=obj; break; } } // peut etre utilisé sous une forme proche de (orig et dest étant des // cConteneur ;) ) dest.place(orig.zerote(3),2);

---

Hé ben !

Je vois que ma question en suscite bien d'autres....

En fait, le vrai probleme de départ, c'est pour le conteneur :

Au moment où il doit ouvrir un objet, comment savoir s'il doit d'abord le créer ?

Car 3 cas existent :
- c'est la premiere fois que l'objet est ouvert, il faut le créer
- l'objet est deja créé, il faut juste l'ouvrir
- l'objet a déjà été ouvert, mais il s'est fermé tout seul, il faut le re-créer

(on peut ré-ouvrir un objet déjà ouvert)

Le vrai souci, c'est de tester si l'objet existe ou pas (si on doit le créer ou pas) car je voudrais éviter de mettre une série de booléen dans le conteneur (du genre bObjet1Ouvert, bObjet2Ouvert....) et de devoir les tenir à jour...

(il y a différentes raisons à cela)

Le plus simple, je crois, va finalement être de créer un "superObjet" qui contient lui-même uniquement 2 choses :
- l'objet
- un booléen bCréé

Afin de determiner si l'objet est crée ou non... sauf que je trouve ça un peu lourd :-)

C'est quoi le contexte d'utilisation ? Tu peux mettre des noms réels sur Conteneur et Objet pour qu'on situe mieux le problème ?

Je crois qu'avant d'essayer d'aller plus loin, il nous faudrait d'avantage de renseignements, entre autres, ne serait-ce qu'un(e partie de) code minimum compilable mettant en scene l'objet et le conteneur, de manière à savoir ce qu'il en est...

Au pire, si tu nous expliquait déjà en quoi consiste le fait qu'un objet soit "ouvert" ou "fermé", ce qu'il permet quand il est ouvert, et ce qu'il permet quand il est fermé, et un ordre d'idée sur l'application que tu tentes de mettre au point :question:

Désolé de poser ces questions, mais, ma boulle de cristal est en panne... et, si tu veux une réponse efficace, il faut nous aider à t'aider ;):D

EDIT grilled :P