Discussion :

[tarekphp]

j'arrive pas trop bien a comprendre les destructeur en c++
et come jai une application qui bouffe enormemant de memoire je veut liberer ce que j'ai a chaque boucle

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
 
void Matrice3D::CalculMatrice(){
	float pas = 2./DIM;
 
	Line3 *lignex;
        for (int k=0; k<DIM;k++)
		for (int i=0; i<DIM;i++)
			for (int j=0; j<DIM;j++)
			{
 
			lignex = new Line3(*new Vector3(k*pas,i*pas, j*pas),
				*new Vector3(k*pas,i*pas, j*pas));
 
 
				// jai pas encore fait le code ici
 
 
			}
		delete lignex;
 
 
}

ça me fait un segmentation fault

je comprends pas trop et de l'autre coté j'ai

Code :

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

1
2
3
4
5
6
7
 
Line3::~Line3()
	{
	//the self destruction
 
	delete this;
	};

voila si quelq'un peut me dire koi faire

merci

[bolhrak]

Hello,

Plusieurs remarques.

1] D'abord sur le fonctionnement des destructeurs. Lorsque tu écris :

Code :

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

1
2
 
delete p;

Avec p de type A*, le compilateur génère le code suivant :

Code :

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

1
2
3
 
p->~A();
free(p);

Autrement dit appel du destructeur puis libération de la mémoire. Ton destructeur pose donc problème, en appelant delete *this, en théorie tu crées une boucle infinie d'appel du destructeur et de libération mémoire. En pratique, vu que tu tentes de libérer deux fois la même zone mémoire, tu plantes le programme.

2] Ta boucle leak. Dans ton cas, si tu veux libérer la mémoire, il faut le faire dans le scope où elle est allouée. Dans ton code, tu alloues DIM-1 Line3 pour ta troisième boucle, mais n'en libère qu'une après cette boucle. Un code sans leak :

Code :

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

1
2
3
4
5
6
7
8
9
 
for(int i = k = 0; k < DIM; k++)
    for(int i = 0; i < DIM; i++)
        for(int j = 0; j < DIM; j++)
        {
            lignex = new Line3(....);
            //...
            delete lignex;
        }

3] L'allocation/libération dynamique est plus coûteuse qu'une allocation/désalocation sur la pile. Ddans la mesure où tu n'as pas besoin de ta variable lignex en dehors de ta troisième boucle, tu devrais plutôt opter pour le code suivant :

Code :

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

1
2
3
4
5
6
7
8
 
for(int i = k = 0; k < DIM; k++)
    for(int i = 0; i < DIM; i++)
        for(int j = 0; j < DIM; j++)
        {
            Line3 lignex(....);
            //...
        }

Et là plus de soucis de mémoire à libérer.

4] Apparemment ton destructeur de Line3 ne désalloue rien, alors que tu passes à son constructeur des paramètres alloués dynamiquement ; comme tu ne gardes aucun pointeur sur ces éléments tu n'as aucun moyen de les désallouer ensuite, et ça leak. Il faut donc que tu passes directement des pointeurs à ton constructeur Line3, et le destructeur se chargera des les libérer (ou mieux tu utilises des auto_ptr), ou que tu passes des variables automatiques et ton constructeur en fait une copie.

[koala01]

Salut,

Il y a vraisemblablement une mauvaise compréhension de ta part sur le travail effectué par delete et par le destructeur.

delete va travailler en deux temps:

1. invoquer le destructeur de l'objet au sujet duquel il est appelé (obj->~MaClasse(); )
2. libérer la mémoire qui a été allouée dynamiquement pour cet objet (free(obj); ).

Le but du destructeur est, prour sa part, de "faire le ménage" non pas de l'objet, mais... des membres qui le composent.

Cela peut aller jusqu'à invoquer delete sur les... membres de l'objet pour lesquels de la mémoire a été allouée dynamiquement.

En outre, this est un pointeur sur... l'objet lui-même, ce qui permet d'avoir un "point d'entrée" pour accéder aux différents membres et méthodes de l'objet lui-même, une fois que l'on se trouve dans une méthode de l'objet.

C'est la raison pour laquelle, il ne faut - à de très rares exceptions près (je ne connait que le pattern "singleton" qui justifie de le faire) - ne jamais invoquer delete sur le pointeur this, et, en tout état de cause, jamais dans le destructeur.

En effet, si l'on décide même de ne pas prendre le coté récursif d'un destructeur proche de

Code :

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

1
2
3
4
5
6
7
8
 
MaClass::~MaClass()
{
    delete this;
    /* ce qui revient à peut de chose près à
     * this->~MaClass();
     * free(this);
}

lorsque que tu invoque delete sur un objet sous la forme de
delete obj;
cela revient à peut de chose près à écrire un code proche de

Code :

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

1
2
obj->~MaClass();
free(obj);

et, comme tu demanderais dans ~MaClass de ... libérer la mémoire allouée à this, pointant pour l'occasion sur obj, lorsque tu arrive à free(obj), il se fait que la mémoire qui lui était allouée a ... déjà été libérée.

Au final, si l'on peut considérer qu'aucune méthode de ligne n'invoque un new d'allocation dynamique sur un des membres de la classe Line3, supprime simplement le delete du destructeur de Line3et laisse le destructeur vide.

Si, par contre, certains membres de Line3 sont gérés sous la forme de pointeurs pour lesquels une gestion dynamique de la mémoire est utilisée, contente toi d'invoquer delete (ou delete[], selon le cas) pour ... les membres qui sont dans le cas

[bolhrak]

C'est la raison pour laquelle, il ne faut - à de très rares exceptions près (je ne connait que le pattern "singleton" qui justifie de le faire) - ne jamais invoquer delete sur le pointeur this, et, en tout état de cause, jamais dans le destructeur.

Je ne vois pas en quelle implémentation du pattern singleton justifie l'emploi de delete this, a priori l'allocation et la libération d'un singleton se font via des fonctions statiques qui allouent/détruisent un pointeur statique. A quel type d'implémentation fais tu référence ?

J'aurais plutôt vu le cas d'un programme multithread, quand un thread est le seul à savoir quand il doit mourrir.

[koala01]

En fait, j'étais un peu mal réveillé au moment d'écrire le message, et je me suis mal exprimé...

Ce n'est bien évidemment pas sur this qu'il faut invoquer delete, mais sur l'instance statique du singleton

D'aucuns estiment d'ailleurs avec raison qu'il n'y a normalement pas lieu de permettre à l'utilisateur de permettre de libérer cette ressource pour des raisons plus que valables

[tarekphp]

Ok merci
j'ai mieux compris maintenant

encore merci