Fuites mémoire

Bonjour à tous,

J'aimerais savoir si le code suivant produit des fuites mémoires:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

void CBase::DoSomeThing() { CString* pMyString; pMyString = new CString(); pMyString->Empty();   *pMyString = returnastring();   // store pMyString in a Vector that will be freed by CBase::~Dtor..   }   CString CBase::returnastring() { CString justastring; justastring = "Kikoo Dvp";   return justastring; }

---

Pour moi il en produit mais je ne sais pas comment adapter celà.
De même, pour la fonction "returnastring", est ce autorisé ce genre d'écriture?? je veux dire, retourner une variable locale et la stocker dans un vecteur qui sera utilisé bien après la mort de la fonction (et donc du destructeur de la cstring locale?)?

Je dois pas être super bien réveillé, j'ai vraiment du mal avec cette partie..

S'il faut des précisions, n'hésitez pas :)

François

Citation:

---

Envoyé par squale32

J'aimerais savoir si le code suivant produit des fuites mémoires

---

oui.
A chaque new doit correspondre un delete.

Citation:

---

Envoyé par squale32

De même, pour la fonction "returnastring", est ce autorisé ce genre d'écriture?? je veux dire, retourner une variable locale et la stocker dans un vecteur qui sera utilisé bien après la mort de la fonction (et donc du destructeur de la cstring locale?)?

---

Oui. C'est une copie qui va être renvoyée.

Citation:

---

Envoyé par spoutspout

oui.
A chaque new doit correspondre un delete.Oui. C'est une copie qui va être renvoyée.

---

Le delete qui correspond au new se trouve plus loin dans le programme. (pointeur stocké dans un vecteur et libéré tout à la fin).

Quant à la copie retournée, doit-elle est libérée à l'aide d'un delete?


J'aimerais en fait savoir si à la ligne suivante:

Code:

---

*pMyString = returnastring();

---

... savoir si une deuxième CString est créée ou pas et si je perds le résultat du new 2 lignes plus haut??

en bref, savoir si à part le delete dans le vector, j'ai autre chose à libérer.

Citation:

---

Envoyé par squale32

Bonjour à tous,

---

Bonjour à toi,

Citation:

---

Envoyé par squale32

J'aimerais savoir si le code suivant produit des fuites mémoires:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

void CBase::DoSomeThing() { CString* pMyString; pMyString = new CString(); pMyString->Empty();   *pMyString = returnastring();   // store pMyString in a Vector that will be freed by CBase::~Dtor..   }

---

---

Tout dépend ce que tu entend par 'store pMyString in a Vector that will be freed by CBase::~Dtor..'. Sur ta fonction, telle que tu la donnes, le pointeur pMyString est perdu, en toute logique il manque un delete. Mais si tu as omis un bout de code (store blablabla), peut être que le pointeur est mémorisé ailleurs.

Citation:

---

Envoyé par squale32

Code:

---

1 2 3 4 5 6 7 8

CString CBase::returnastring() { CString justastring; justastring = "Kikoo Dvp";   return justastring; }

---

Pour moi il en produit mais je ne sais pas comment adapter celà.
De même, pour la fonction "returnastring", est ce autorisé ce genre d'écriture?? je veux dire, retourner une variable locale et la stocker dans un vecteur qui sera utilisé bien après la mort de la fonction (et donc du destructeur de la cstring locale?)?

---

Ici, tu ne retourne pas une variable locale mais une copie de cette variable (car ton type de retour est CString et non pas CString&, ou CString*). Donc, pas de soucis. Si tu traces au debugger, tu verras qu'à l'instruction 'return justastring;', tu vas passer d'abord dans le copy-constructeur (pour construrie ta variable de retour), puis dans le destructeur (destruction de ta variable locale justastring). Si tu regardes plus attentivement l'implémentation MFC des CString, tu verras comment la chaîne de caractère est effectivement gérée.

remplace

Citation:

---

CString* pMyString;
pMyString = new CString();
pMyString->Empty();

*pMyString = returnastring();

---

par

Code:

---

CString myString = returnastring();

---

Mais à mon avis, y'a des problèmes encore plus graves dans ton code.

Ou mieux :

Code:

---

CString myString(returnastring());

---

Ça évitera la construction d'un objet à vide.

Citation:

---

Envoyé par 3DArchi

Bonjour à toi,


Tout dépend ce que tu entend par 'store pMyString in a Vector that will be freed by CBase::~Dtor..'. Sur ta fonction, telle que tu la donnes, le pointeur pMyString est perdu, en toute logique il manque un delete. Mais si tu as omis un bout de code (store blablabla), peut être que le pointeur est mémorisé ailleurs.

---

remplacer le commentaire par:

Code:

---

1 2 3 4

myVector.push_back(pMyString);   }

---

Et alors effectivement, à la fin du programme, je boucle dans mon vecteur, j'extrais le pointeur et je le delete. Donc par rapport à cela je pense que je suis bon.

Citation:

---

Ici, tu ne retourne pas une variable locale mais une copie de cette variable (car ton type de retour est CString et non pas CString&, ou CString*). Donc, pas de soucis. Si tu traces au debugger, tu verras qu'à l'instruction 'return justastring;', tu vas passer d'abord dans le copy-constructeur (pour construrie ta variable de retour), puis dans le destructeur (destruction de ta variable locale justastring). Si tu regardes plus attentivement l'implémentation MFC des CString, tu verras comment la chaîne de caractère est effectivement gérée.

---

Construction qui nécessite un delete?

C'est là que se trouve réellement mon problème (au fond de ma tête j'en suis conscient..).

Il a donc bien 2 allocations à libérer si je comprends bien ce que tu me dis?

Citation:

---

Envoyé par squale32

Le delete qui correspond au new se trouve plus loin dans le programme. (pointeur stocké dans un vecteur et libéré tout à la fin).

---

Si tu es sensible aux fuites mémoire, je te suggère de lire l'article sur les pointeurs intelligents.

Citation:

---

Envoyé par oodini

Ou mieux :

Code:

---

CString myString(returnastring());

---

Ça évitera la construction d'un objet à vide.

---

Il me semble que c'est équivalent à

Code:

---

CString myString = returnastring();

---

Pour autant que je me souvienne, l'instruction combinant déclaration et initialisation, c'est directement un appel au constructeur qui est réalisé, et non un création à vide puis l'opérateur d'affectation.

Oui. J'avais cru voir une paire de () myString.

Mea culpa.

Me revoici, désolé pour le temps de réponse...

Merci pour l'article oodini, je l'avais déjà lu et le trouve effectivement très intéressant, mais malheureusement inapplicable dans le cas qui m'occupe (Projet professionnel avec des vilains délais à tenir :( ).
..Ce code faisant partie des nombreuses portions de code que j'ai à vérifier..

Sinon, concernant

Code:

---

1 2	CString myString(returnastring());

---

cela se trouve dans une boucle et les strings résultantes sont stockées dans un vector qui sera utilisé plus tard dans une autre fonction.
le new est donc obligatoire je pense ...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

void CBase::DoSomeThing() { while (plusrienafaire) { CString myString(returnastring());   myVector.push_back( & myString); }   // ici mon vecteur ne contient plus rien de bon :/   }

---

Dû au nombre de ligne codées autour cette fonction, je ne peux me permettre de changer mon vecteur pour qu'il accepte directement les CString et non plus des pointeurs de cstring..
De toute façon, niveau occupation mémoire, il est plus intéressant de stocker les pointeurs..

Citation:

---

Envoyé par oodini

Oui. J'avais cru voir une paire de () myString.

Mea culpa.

---

Ok, no soucy 8-)

Ca ne marchera pas.
Sorti de ton while, les adresses ne seront plus valides car elles pointent vers des copies de l'élément CString créé par le new et non pas l'élément lui-même qui subsistera jusqu'au delete associé.

A la base myString était un CString* et non un CString, il me semble qu'il a posté ce code pour montrer qu'avec les modifications qu'il aurait voulu apporter il devenait incohérent (enfin, si j'ai bien compris son intention).

Code:

---

1 2 3 4 5

void CBase::DoSomeThing() { while (plusrienafaire) myVector.push_back(returnastring()); }

---

est la solution optimale dans une implémentation move-aware.

Après si pour une raison (probablement stupide) tu veux avoir des pointeurs, il faut faire

Code:

---

1 2 3 4 5

void CBase::DoSomeThing() { while (plusrienafaire) myVector.push_back(new CString(returnastring())); }

---

qui fera deux copies ou aucune, suivant si CString et ton type vector sont move-aware ou non.

Citation:

---

Envoyé par Noxen

A la base myString était un CString* et non un CString, il me semble qu'il a posté ce code pour montrer qu'avec les modifications qu'il aurait voulu apporter il devenait incohérent (enfin, si j'ai bien compris son intention).

---

C'est effectivement celà, je rajouterais que mon objectif premier était d'éliminer les éventuelles fuites mémoires.
La question réelle étant :

Code:

---

1 2 3 4 5 6

CString* pMyString; pMyString = new CString(); pMyString->Empty();   *pMyString = returnastring();

---

Est ce qu'à la dernière ligne, je perds le résultat du new ?
Autrement dit, y aura t il 2 delete à faire ou un seul?


@ loufoque:

Citation:

---

Mais à mon avis, y'a des problèmes encore plus graves dans ton code.

---

Citation:

---

Après si pour une raison (probablement stupide) tu veux avoir des pointeurs

---

Tu ne serais pas un peu provocateur toi ?? ;)

Sinon "move-aware", jamais entendu parler.. Tu peux préciser?

Les pointeurs j'en ai besoin car la portée du vecteur dépasse celle de la fonction.
J'ai pris un raccourci que je n'aurais peut être pas du prendre en ne postant qu'une petite partie du code..
J'avais pas envie de vous mettre 30 pages de code...


@ spoutspout:
Effectivement, c'était un contre exemple pour montrer que j'avais besoin des pointeurs..

Ce code ne produit pas de fuites mémoires, il revient au même que

Code:

---

1 2 3

int * pi = new int;   *pi=3;

---

(Bien sur, il faut deleter pi plus loin)

Citation:

---

Envoyé par squale32

Est ce qu'à la dernière ligne, je perds le résultat du new ?
Autrement dit, y aura t il 2 delete à faire ou un seul?

---

Un seul, celui associé au new.
Dans ton code, tu créées un CString quelque part en mémoire en gardant son adresse pour y accéder (= pointeur). Puis tu copies le retour de ta fonction dans ce CString. Tous les éventuels CString qui t'ont servi dans ta fonction returnasstring() auront déjà été supprimés au retour dans le main. Il n'y a que celui quelque part en mémoire à supprimer via le pointeur. Un delete va appeler le destructeur de CString et libérer proprement la-dite mémoire.

Citation:

---

Envoyé par squale32

Les pointeurs j'en ai besoin car la portée du vecteur dépasse celle de la fonction.
J'ai pris un raccourci que je n'aurais peut être pas du prendre en ne postant qu'une petite partie du code..
J'avais pas envie de vous mettre 30 pages de code...


@ spoutspout:
Effectivement, c'était un contre exemple pour montrer que j'avais besoin des pointeurs..

---

Si tu utilises un vector<CString>, à chaque push_back() ce n'est pas le CString lui-même qui sera inséré dans le vector, mais une copie. Le contenu du vector sera alors toujours valide même après la sortie de la fonction.

Sinon cela voudrait dire que pour passer d'une fonction à une autre en C++, on aurait pas d'autre choix que de passer par des pointeurs!

Merci à tous pour toutes ces précisions,
Le code ne produit donc pas de fuites mémoires. :D


Une dernière question à spoutspout par rapport à sa dernière remarque:

Si myVector est défini comme suit: vector<CString>;

Code:

---

1 2 3

CString myString = returnastring(); myVector.push_back(myString);

---

La copie de myString sera t elle détruite toute seule ou vais je devoir appeler moi même le destructeur à l'aide d'un delete? :oops:
D'après moi ce sera fait tout seul par la fonction clear() du vector qui appelle les destructeurs 'direct' des objects stockés (mais pas des pointeurs), suis je dans le bon?


Encore merci à tous

Citation:

---

Envoyé par squale32

La copie de myString sera t elle détruite toute seule ou vais je devoir appeler moi même le destructeur à l'aide d'un delete? :oops:
D'après moi ce sera fait tout seul par la fonction clear() du vector qui appelle les destructeurs 'direct' des objects stockés (mais pas des pointeurs), suis je dans le bon?

---

Oui.
En fait, j'ai l'impression que tu as encore un peu de mal avec les pointeurs, les objets, les copies implicites etc... Tu devrais peut-être jeté un coup d'oeil dans les tuto:http://cpp.developpez.com/cours/

myString sera détruit à la sortie du bloc, alors que sa copie intégrée dans myVector subsistera tant que myVector existera. Ce qui n'aurait pas été le cas si tu avais utilisé des CString*.

Mais je suis d'accord avec 3DArchi, tu parais encore confus sur la gestion des objets et leur portée. Les cours du site sont très bien faits pour combler cette lacune ;).

Citation:

---

sa copie intégrée dans myVector subsistera tant que myVector existera.

---

non, pas tout a fait. en cas de "resize" il se peut que la copie soit a nouveau dupliquée pour aller ailleurs. c'est pourquoi on ne peut pas faire :

Code:

---

1 2 3

CString str("blabla"); vector.push_back(str); return &vector.back(); //retourne l'adresse de ce qu'on a mis dans le vecteur

---

Si tu écris

Code:

---

1 2	CString foo = bar(); v.push_back(foo);

---

foo sera forcément copié.

Si tu écris

Code:

---

v.push_back(bar());

---

Il ne le sera pas.

Bien sûr. La STL gérant toute seule le fonctionnement de ses conteneurs, chaque modification de la structure de celui-ci peut entrainer un remaniement complet de la zone mémoire occupée par le conteneur, ce qui implique une invalidation de toutes les références au contenu avant la-dite modification.

Mais de toute façon la question ne se pose plus vu qu'à priori, il n'utilise plus de pointeurs.

Citation:

---

Envoyé par loufoque

Si tu écris

Code:

---

1 2	CString foo = bar(); v.push_back(foo);

---

foo sera forcément copié.

Si tu écris

Code:

---

v.push_back(bar());

---

Il ne le sera pas.

---

oui enfin c'est un enorme raccourci. ca serait bien des fois que tu sois moins categorique quand tu ecris sur des trucs specifiques a des compilos ou des settings d'optimisation, car la malgré tout je parie 10 couronnes que l'objet est copié sous VS2005 ou sous GCC.

Ça s'appelle les sémantiques de mouvement. Le compilateur est obligé de déplacer.
C'est dans la prochaine norme de C++. Il vaut mieux commencer dès maintenant à écrire du code moderne, même si on ne bénéficie pas des optimisations de suite.