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: