Validité du code

Bonjour à tous.
Voici un petit code un peu tordu:

Code:

---

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

class A { A* ma; public: ~A(){delete ma;} A(A* a):ma(a){} void foo(A* a){delete a;} void bar(){ma->foo(this);} };   int main(int argc, char const *argv[]) { (new A(new A(0)))->bar(); return 0; }

---

La grande question que je me demande, c'est la correction de ce code.
En effet, après la destruction de l'objet qui appelle bar, il y a retour à lui mais il n'existe plus, c'est plutôt problématique.
le code ne plante pas chez moi, mais ce n'est pas une preuve. Je pense que ca ne plante pas car je ne manipule pas de données membres, mais je n'en suis pas sûr.

Quelqu'un pour confirmer ?
Merci.
David Côme.

Salut,

Le code est correct, même si on peut se demander l'usage qui peut en être fait, et, surtout, s'il faut attirer l'attention sur le fait que deux pointeurs risquent d'être invalidés

En effet, si l'on étend un peu le code, on a

Code:

---

1 2 3 4 5 6 7

A * t1=new A(0); A * t=new A(t1); t->bar() /* ce qui revient à */ t1->foo(t) /* destruction de t, impliquant la destruction de t2 */ /* !!! t1 est invalidé du fait de la destruction de t et  * !!! t est détruit du fait de l'appel à bar avec t en parametre  */

---

Mais, il n'est pas impossible d'assister à la libération de la mémoire allouée à un pointeur dans une fonction qui est appelée depuis le dit pointeur...

Il faut cependant être attentif au fait que... cela doit être la dernière action effectuée dans la fonction et... au départ du pointeur concerné ;)

Ok, merci beaucoup pour tout.

Je trouve ça plutôt dangereux de donner le droit à n'importe qui de liberé les ressources d'un objet de cette façon. Dans le principe d'encapsulation l'objet dois être en mesure de garantir en tout temps son intégrité, peut importe ce que tu appel comme fonction, elle ne doit pas mettre en péril le bon fonction de l'objet. C'est l'objet qui dois décider de ce qu'il libère et quand. Ou alors la fonction foo dois être private et être utilisé que par l'objet mais pas a la disposition du code client.

Citation:

---

Envoyé par Astraya

Je trouve ça plutôt dangereux de donner le droit à n'importe qui de liberé les ressources d'un objet de cette façon. Dans le principe d'encapsulation l'objet dois être en mesure de garantir en tout temps son intégrité, peut importe ce que tu appel comme fonction, elle ne doit pas mettre en péril le bon fonction de l'objet. C'est l'objet qui dois décider de ce qu'il libère et quand. Ou alors la fonction foo dois être private et être utilisé que par l'objet mais pas a la disposition du code client.

---

Nan mais là c'est du code de test (ca se voit pas ? :aie:). je m'en sert pour vérifier que j'ai le droit de le faire, je ne vais pas utiliser ca comme ca dans mes projets :aie:

Citation:

---

Envoyé par Astraya

Je trouve ça plutôt dangereux de donner le droit à n'importe qui de liberé les ressources d'un objet de cette façon. Dans le principe d'encapsulation l'objet dois être en mesure de garantir en tout temps son intégrité, peut importe ce que tu appel comme fonction, elle ne doit pas mettre en péril le bon fonction de l'objet. C'est l'objet qui dois décider de ce qu'il libère et quand. Ou alors la fonction foo dois être private et être utilisé que par l'objet mais pas a la disposition du code client.

---

A vrai dire, la question était "est-ce valide", et, à cette question, il faut bien répondre par l'affirmative...

Maintenant, s'il s'agit de répondre à la question "est utile / intéressant / prudent d'agir de la sorte?", il faut avouer que la réponse est souvent non... l'un n'empêchant absolument pas l'autre ;)

Il est, en effet, plus fréquent de se trouver dans une situation dans laquelle le contenant (t dans le code que je présentais plus tot) détruire le contenu (t1 dans le même code), que de voir le contenu provoquer la destruction du contenant...

Mais cela ne veut pas dire qu'il n'y ait aucune situation dans laquelle cela puisse arriver ;)

L'idée de base, c'est une frame contient des fenêtres et un pointeur vers la frame parent. Elle se passe à son parent, la parent s'accapare toutes les fenêtres, puis elle se fait détruire par son parent et détruit ses frames enfants. Mais j'avoue, tel que c'est là, ce n'est pas évident du tout.

Il faut noter que si j'utilise ce système, y'aura des modifications, là j'insiste c'est vraiment pour le proof of concept

Ah ok!!
Si je comprend bien, le parent détruit ses petits enfants?
j'avoue être perdu mais pourquoi pas ^^

Citation:

---

Envoyé par Astraya

Ah ok!!
Si je comprend bien, le parent détruit ses petits enfants?
j'avoue être perdu mais pourquoi pas ^^

---

Plus l'enfant qui demande à son père de se faire tuer pour pour que ce dernier ait la garde des petits enfants mais le code n'exprime pas cette idée là, c'est juste l'idée de base qui à motivé son écriture.

Voici le code qui exprimerai cette idée (non testé)
je saute volontaire tous les tests & co, seule l'idée compte, le code est moche, I know :aie:.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

class Frame { Frame* parent; std::vector<Frame*> enfant; public: ~Frame(){for_each(enfant.begin(),enfant.end(),deleter());} Frame(Frame* a):parent(a){}   void disparaitre(){parent->merge(this);} protected: void merge(Frame* a){ //On choppe les fênetre de la frame a; delete a;} };   int main(int argc, char const *argv[]) { Frame* parent=new Frame(0); Frame* enfant=new Frame(parent); enfant->disparaitre(); return 0; }

---

As d'accord je vois mieux :) j'avoue avoir été un peu perdu :aie: