Destructeur de classe - remise à NULL

**buzzkaido** · 23/03/2007, 09h13

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 :

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

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 !

**Laurent Gomila** · 23/03/2007, 09h19

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.

**buzzkaido** · 23/03/2007, 09h22

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)

**Laurent Gomila** · 23/03/2007, 09h39

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.

**buzzkaido** · 23/03/2007, 09h56

Ouais, je vais essayer d'etre plus clair :

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

du genre :

Code :

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

1
2
3
4
5
6
7
cConteneur
{
    cObjet    *pObjet1;
    cObjet    *pObjet2;
    cObjet    *pObjet3;
    cObjet    *pObjet4;
}

Le constructeur : (aucun objet n'existe)

Code :

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

1
2
3
4
5
6
7
8
 
cConteneur::cConteneur()
{
    pObjet1 = NULL;
    pObjet2 = NULL;
    pObjet3 = NULL;
    pObjet4 = NULL;
}

Le destructeur :

Code :

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

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 :

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

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

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

**Laurent Gomila** · 23/03/2007, 10h23

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.

**Patriarch24** · 23/03/2007, 10h30

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.

**Startux** · 23/03/2007, 10h38

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

Code :

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

1
2
3
4
5
6
 
CContainer::liberer(*Objet)
{
       Objet->fermer();
       Objet = NULL;
}

non ?

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

**buzzkaido** · 23/03/2007, 10h50

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

**Ulmo** · 23/03/2007, 12h00

Envoyé par buzzkaido

Code :

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

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.

**Laurent Gomila** · 23/03/2007, 12h04

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.

**koala01** · 23/03/2007, 12h53

Salut,

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

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

(ou alors, il y a du code qui manque

)

**Ulmo** · 23/03/2007, 13h03

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 ?

**Laurent Gomila** · 23/03/2007, 13h18

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.

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 ?

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

**koala01** · 23/03/2007, 13h21

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

**Ulmo** · 23/03/2007, 13h42

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 :

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

1
2
3
4
5
6
7
cObjet::fermer()
{
    fermerDesTrucs();
    delete this;
}
...
UnCObjet->fermer();

par:

Code :

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

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.

**koala01** · 23/03/2007, 13h43

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 :

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

**buzzkaido** · 23/03/2007, 13h51

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

**Laurent Gomila** · 23/03/2007, 13h58

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 ?

**koala01** · 23/03/2007, 13h59

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

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

EDIT grilled