Discussion :

[Davidbrcz]

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

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

[koala01]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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�

[Davidbrcz]

Ok, merci beaucoup pour tout.

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

[Davidbrcz]

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

[koala01]

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

[Davidbrcz]

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

[Astraya]

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