Discussion :

[killwin]

Bonjour,

Je suis sous linux / g++ / gdb

J'ai terminé mon programme, en libérant soigneusement la mémoire dans mes destructeurs ...

Cependant j'ai des oublis et des fuites mémoire importantes ici ou là et j'aimerais contrôler tout ça méthodiquement !

J'ai aussi des déclarations de variables ou d'objets inutiles qui doivent trainer un peu partout. Voilà j'aimerais contrôler tout ça avec des outils ou des méthodes. Merci

[mirecalu]

Bonjour,

Pour tes fuites mémoire, tu peux utiliser valgrind

[LittleWhite]

Bonjour,

Pour les variables inutilisées, rajouté les options

-Wall -Wextra

à la compilation sera bénéfique
(Surtout le -Wextra qui rapport les variables inutilisées)

[killwin]

Merci, on m'en avait parlé et j'avais oublié cet outil, je vais bosser avec valgrind maintenant. C'est exactement ce que je cherchais.

[Bousk]

Bonjour,

dans le genre intéressant à voir pour la technique, tu peux aussi surcharger les opérateurs new et delete (new[] et delete[]), afin de faire un suivi des (dés)allocations.

[killwin]

Ha oui, c'est vrai, j'avais entendu parler de cette technique. Merci

[Davidbrcz]

Avec une bonne dose de RAII, tu n'as normalement aucune fuite de mémoire.

[jblecanard]

Avec une bonne dose de RAII, tu n'as normalement aucune fuite de mémoire.

Avec une bonne dose de code parfait, tu n'as normalement aucun bug.

Le RAII est effectivement une bonne méthode à appliquer en C++, mais cela n'empêche pas de faire des erreurs (qui peuvent se traduire par des fuites). Seuls des outils comme Valgrind permettent de valider une bonne gestion de la mémoire.

[killwin]

Pour la question du RAII :

Mes problèmes de codage propre :

J'utilise une bibliothèque destinée au C dans mes classes. Donc je me trimbale pas mal de pointeurs ici ou là.

J'ai des objets qui prennent beaucoup de mémoire vive. Donc je libère genre 40% de l'objet en cour de route et le reste dans mon del_datas.cpp

Sinon à coup de valgrin et de gdb / meminfo j'ai libéré beaucoup de mémoire.

Cependant j'ai encore 80 Mégas sur un total de 200 Mégas qui ne sont pas libérés juste avant mon exit(0)

[cob59]

Il te faudrait une classe wrapper pour gérer les alloc/désalloc de ta lib C selon le principe RAII. Cf cet article Wikipédia : http://en.wikipedia.org/wiki/Wrapper_library#Example

[jouana]

Bonjour,

Je sais que dans ton cas c'est un peu tard mais pour ma part j'utilise le design pattern smart pointer cela permet de mettre en place une dés-allocation dynamique et un peu plus sur.

Juste comme ça pour tes futurs projets

Bonne journée

[rmaker]

Bonjour,

dans le genre intéressant à voir pour la technique, tu peux aussi surcharger les opérateurs new et delete (new[] et delete[]), afin de faire un suivi des (dés)allocations.

Une variable statique qui compte le nombre d'allocations et de désallocations mise à jour dans chaque new et delete, c'est trop violent? Ou c'est à çà que tu pensais?

[jblecanard]

Une variable statique qui compte le nombre d'allocations et de désallocations mise à jour dans chaque new et delete, c'est trop violent? Ou c'est à çà que tu pensais?

Pour faire un test qui reste côté dev et qui n'est pas livré, pourquoi pas, mais ça risque de ne pas beaucoup t'aider à trouver quel objet n'a pas été delete. Un compteur unique pour tous les objets n'est pas une info très intéressante, tu vas te retrouver avec un compteur énorme qui a peu de sens.

[nikko34]

Pour faire un code sans problème de fuite mémoire:

- ne jamais faire de new et donc de delete ( donc ne pas utiliser de pointeurs)
- si vraiment on doit utiliser des pointeurs:

- ne pas utiliser de pointeurs
- si on est pas sûr, utiliser des références
- si on est vraiment sûr de savoir pourquoi on utilise un pointeur:

- utiliser un pointeur intelligent comme le shared_ptr ( comme dans boost::shared_ptr ou tr1::shared_ptr ou en standard dans C++11 )

Du coup, normalement tu ne devrais jamais écrire "delete".

[jblecanard]

- ne jamais faire de new et donc de delete ( donc ne pas utiliser de pointeurs)
.

Il ne faut pas confondre l'usage de pointeurs et l'allocation dynamique. Il est rare de pouvoir écrire un programme complet sans allocation dynamique. Quant à se passer de pointeurs, n'y pensez même pas : même si vous écrivez votre code sans pointeurs et sans allocations dynamiques, il y a peu de chances que vous trouviez des bibliothèques qui n'en utilisent pas.

- utiliser un pointeur intelligent comme le shared_ptr ( comme dans boost::shared_ptr ou tr1::shared_ptr ou en standard dans C++11 )

Attention aux smart pointers, qui représentent une solution de facilité dans beaucoup de cas mais qui doivent être utilisés avec intelligence et en compagnie des std::weak_ptr, des std::uniq_ptr (C++11) et des pointeurs nus. Voici un article qui traite du sujet.

[nikko34]

Je te l'accorde, c'est une simplification.

Le problème des fuites mémoires en C++, et je ne pense pas que ça ait beaucoup changé en quelques années, a toujours été un usage abusif des pointeurs qui entraine des fuites mémoires, souvent par inadvertance (oubli d'un delete, exception malencontreuse).

La première règle est donc de n'utiliser des pointeurs seulement quand ils sont nécessaires. Et donc de savoir en quoi ils sont nécessaires en C++.

De la même façon, cette règle inclus aussi le fait de n'utiliser les pointeurs intelligents que quand ils sont nécessaire. std::unique_ptr (C++11) fait parti des pointeurs intelligents.

Un abus de pointeurs intelligents n'est finalement qu'un abus de pointeurs tout court.

En C++, où il est extrèmement important de savoir qui a la responsabilité de quoi ( en gros, quel objet décide de la durée de vie des autres objets ), il y a des cas où on est obligé tout de même d'utiliser des pointeurs. Et dans ces cas là, bien sûr, je ne me vois pas conseiller autre chose que d'utiliser des pointeurs intelligents ( donc, shared_ptr est un pointeur intelligent mais aussi unique_ptr si on peut, scoped_ptr, weak_ptr etc.. ).

Dans ce cas là, je préfère voir beaucoup de shared_ptr plutôt que des pointeurs nus, même si bien sûr il faudrait avoir plutôt des unique_ptr (ou boost::scoped_ptr) etc.. Déjà si on utilise plus de pointeurs quand c'est inutile et qu'on se protège avec des pointeurs intelligents (même si ce sont des shared_ptr inutiles dans beaucoup de cas), on devrait ne pas avoir de fuites mémoires.