Discussion :

[Zenigata]

Bonjour,

j'avais un problème de fuites de mémoire dans un programme de calcul symbolique qui représente les fonctions sous forme d'arbre binaire.

Typiquement des que je mettais un destructeurs classique qui tue les fils, ça me donnait des segfaults de partout.

Les segfaults se produisent lors de la destruction d'un nœud ayant des successeurs.

J'ai donc décidé d'essayer de remplacer mes pointeurs par des auto_ptr, qui je crois sont censés aider dans la gestion des destructions des objets dynamiques.

Et là étrange problème, mes constructeurs ne marchent plus,par exemple pour créer une fonction constante, j'ai la classe number, si dans un programme j'écris

Code :

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

1
2
 
number One=number(1);

le compilateur me dit

Code :

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

1
2
3
4
5
 
erreur, no matching function to call number:number(number).
les candidats sont: 
number.h(l56)         number:number(double)
number.h(l41)         number:number(number&)

Alors d'une part c'est étrange car je n'ai aucune idée de la manière dont mon code s'est mis à considérer les doubles comme des "numbers", et sont deuxième candidat n'est autre que la ligne de déclaration de la classe number

Code :

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

1
2
3
 
class number : public noeud {
....

En fichier joint, il y a les deux versions de mon code

src_std_ptr.tar.bz2 est la version qui compile, tourne, mais a d'énormes fuites (et dans laquelle je n'arrive pas à définir de destructeur)

src_std_auto_ptr.tar.bz2 est la version avec des auto_ptr, qui confond les doubles et les objets de mes classes.

Si quelqu'un sait d'où vient l'un ou l'autre des problèmes, je suis preneur, car c'est assez frustrant d'avoir un code dans lequel on n'arrive pas à mettre les destructeurs dans le premiers cas, et dans le deuxième qu'on n'arrive pas à tester.

Merci bien.

--
Z.

[Médinoc]

Euh, non, pas trop:
Le premier candidat est le constructeur de number à partir de double, et le second est un constructeur de copie de number.

Aucun des deux n'est valides car il faut un constructeur de copie prenant en paramètre une référence const.

Ce problème vient du fait que le C++ refuse les références non-const de temporaires non-nommés.
Et ta ligne number One = number(1); crée un temporaire non-nommé et tente d'appeler le constructeur de copie dessus. Pour ne pas faire de copie, il suffirait de faire number One(1);

[Zenigata]

Mmh intéressant, ça règle en effet le cas du auto_ptr, merci beaucoup.

Il reste que je ne comrepnd pas pourquoi dans la version sans auto_ptr je pouvais écrire

number One=number(1)

Alors que maintenant je ne peux plus.

Merci encore.

--
Z.

[Médinoc]

Typiquement, les auto_ptr<> ont un constructeur de copie non-const (puisqu'ils ont une sémantique de transfert et non de copie). Ça peut être lié à ton problème...

D'ailleurs, en regardant ton code, je me demande si auto_ptr est bien le meilleur type pour ce que tu cherches à faire...
Notamment, ta fonction noeud::prec() supprimme le pointeur prec du noeud. Est-ce vraiment ce que tu veux faire ?

[Zenigata]

D'ailleurs, en regardant ton code, je me demande si auto_ptr est bien le meilleur type pour ce que tu cherches à faire...

Oui, pour ça je n'en sais rien, mais le truc et que je n'ai pas réussi à faire de destructeur viable avec les pointeurs normaux, donc j'essaye les auto_ptr pour limiter les fuites car elles atteignent un niveau impressionnant.

[Médinoc]

Ça ne marchera pas.

Si tu veux vraiment avoir des pointeurs avec des destructeurs, utilise la bibliothèque boost et ses shared_ptr<> (ou bien des intrusive_ptr<>) : Ce sont des pointeurs à comptage de références.

[Zenigata]

noeud::prec() supprimme le pointeur prec du noeud

Avec un

Code :

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

1
2
 
return preced;

je supprime un quelconque pointeur ?

dans l'esprit de ce que je voulais faire c'était juste donner un moyen public d'accès en lecture au pointeur du noeud parent d'un noeud....

Doit y avoir mille choses que je n'ai pas comprises....