Discussion :

[schtroumpf_farceur]

Je ne perds pas beaucoup de mémoire mais étant donné que j'appel ma fonction extrémement souvent, je rempli tout, c'est à dire le Giga de RAM et les 512 Mo de swap.

J'utilise donc le template list pour faire une liste.
Je fais mon allocation normal mais j'ai quelques problèmes au niveau de la désallocation.

Code :

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

std::list<C_job *> *liste_job = new std::list<C_job *>;

je la déclare de cette maniére, j'ai donc un pointeur vers une liste de pointeur vers des objet de type C_job.

j'effectue la désallocation de la sorte :

Code :

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

1
2
3
4
5
6
7
8
std::list<C_job *>::iterator indice;
for(indice = liste_job->begin(); indice != liste_job->end();indice++)
{
	//je désalloue mon objet
	delete *indice;
}
//je désalloue maintenant la liste
liste_job->erase(liste_job->begin(),liste_job->end());

et pour finir, dans mon programme, je désalloue le pointeur vers list

Code :

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

delete liste_job;

J'aimerais savoir si ma désallocation est faite correctement?

Merci d'avance.[/code]

[sas]

A première vue la désallocation a l'air correcte, reste à savoir ce que contient C_job, s'il a aussi des pointeurs dans ces membres, faudrait les désallouer.
Sinon es-tu sûr que les fuites mémoires proviennent de ces list ??

[schtroumpf_farceur]

Dans C_job, j'ai fais correctement mon destructeur donc pas de soucis de ce coté la.

Je ne suis pas sur du tout que le problème vienne de list. Ce serais deja un début de savoir si c'est fais correctement.

[diogene]

Code :

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

1
2
3
4
5
for(indice = liste_job->begin(); indice != liste_job->end();indice++) 
{ 
   //je désalloue mon objet 
   delete *indice; 
}

Cet objet est d'après ce que j'ai compris un pointeur vers quelque chose. Mais qui détruit l'objet pointé (C_job) ?

[schtroumpf_farceur]

ouais, exactement

[sas]

Cet objet est d'après ce que j'ai compris un pointeur vers quelque chose. Mais qui détruit l'objet pointé (C_job) ?

la confirmation est ici

schtroumpf_farceur >> il ne te reste plus qu'à compter tes new/delete de ton code.

[schtroumpf_farceur]

schtroumpf_farceur >> il ne te reste plus qu'à compter tes new/delete de ton code.

le pire, c'est que pour moi tout est correct donc c'est un peu chiant. Je perds pas grand chose à chaque fois mais là ça deviens relou.

[JolyLoic]

Tu peux peut-être ajouter de code de traçage dans tes constructeurs destructeurs pour mieux voir ce qui s'y passe (n'oublie pas les constructeurs que tu n'as pas écrit toi même et qu'il te faudra écrire juste pour tracer, comme d'éventuels constructeurs par recopie).

Autrement, poster ici un ECM (exemple complet et minimal, complet en ce qu'il permet de reproduire le problème et être directement compilable, minimal dans le sens où il ne doit contenir que ce qui permet de reproduire le problème).

[schtroumpf_farceur]

En fait, ça va etre difficile de pouvoir mettre des exemples, car je fais de la programmation par contraintes, en utilisant ECLiPSe qui fais cela en prolog. J'ai codé une contraintes globales en C++. Ce qui veut dire que je ne peut pas la tester comme je veux, c'est plutôt lourd comme manière de faire du code C++. Mais je n'ai pas le choix.

Je ne sais pas si tout le monde m'as compris, en tout cas, ce que je peux dire c'est que je ne pas donner d'exemples.

[Luc Hermitte]

Et ?
Cela n'empêche pas de tester des algos et des bouts de codes dans des programmes de 20 lignes qui ne reposent sur aucunes contraintes autres que le langage.
Sorti des gros debug et des ajouts de traces lourdes dans tout le code, c'est un bon moyen (les ECM) de tester, valider, comprendre, ...

Quant aux listes, mais pourquoi diable les manipuler par référence ("sémantique de .. référence", même si tu utilise pointeurs bruts ou intelligents) ? Elles ont une sémantique de valeur, il faut en profiter.
La liste n'est d'ailleurs pas ce qu'il y a de moins couteux en occupation mémoire. Seul le type de remplissage/vidage (fréquents en plein milieu) peut vraiment justifier cette structure par rapports aux vector et autres deque.