Je suis assez nouveau en C++ mais j'ai des connaissances de base en C. Dans mes projets passés en C (université), j'ai utilisé Valgrind pour vérifier les memleaks. Maintenant, avec C++, Valgrind est-il un outil valide? C++ souffre-t-il des mêmes problèmes concernant les memleaks comme C? Ou y a-t-il encore de meilleurs outils à utiliser avec C++?Valgrind utilisé dans le développement C++?
Je n'utilise jamais new et delete (ou d'autres formes de gestion manuelle de la mémoire) et j'utilise très rarement même des pointeurs. Et je encore doivent lutter avec fuites de mémoire accès mémoire invalide. Valgrind est un outil indispensable pour moi. Encore plus important que gdb.
Comme Viktor a souligné dans un commentaire, produisant des fuites de mémoire sans gestion de la mémoire manuelle serait assez bizarre (actualisation des références circulaires et autres cas particuliers).
Valgrind peut être utilisé pour vérifier memleaks en C++ aussi
valgrind a tellement d'options qui vous donnera les informations et vous pouvez explorer callgrind aussi.
--Cheers
__gVirt_NP_NNS_NNPS<__ fuites de mémoire sont une préoccupation pour moi-même en tant que développeur C++. Je suppose qu'ils sont aussi une préoccupation pour d'autres développeurs, même si je ne peux pas parler pour tout le monde. Valgrind est un outil fantastique dans cet espace et je ne pourrais vraiment pas vivre sans.
Valgrind est le meilleur outil pour traiter les erreurs de mémoire (mais vérifiez les autres modules à côté de memcheck). La programmation en style C est une approche de programmation valide (et largement utilisée) en C++, donc oui, les problèmes de mémoire sont toujours un problème.
N'utilisez que memcheck. Quels autres modules pouvez-vous recommander? – helpermethod
Alors que C++ a une meilleure gestion de la mémoire que C, il est tout à fait possible de gâcher. Les pointeurs intelligents sont excellents, mais il est possible de faire des erreurs avec eux. C'est ce que valgrind est pour.
oui, c'est. J'utilise l'allocation dynamique par défaut dans les tests unitaires (avec des pointeurs automatiques, ou un équivalent idiomatique), pour vérifier explicitement les erreurs de mémoire que Valgrind peut détecter. valgrind, guardmalloc, leaks, etc. peuvent intercepter de nombreuses erreurs avant d'entrer dans le code de production.
ne pas oublier de dire l'exécution gcc de ne pas utiliser sa propre piscine privée de mémoire, sinon vous confondez valgrind
GLIBCPP_FORCE_NEW = 1
Apparemment c'est 'GLIBCXX_FORCE_NEW' de gcc 3.4 et suivantes. vous pourriez vouloir faire un lien vers [FAQ de Valgrind] (http://valgrind.org/docs/manual/faq.html#faq.reports) à ce sujet. – Hasturkun
alors je vous suggère d'utiliser différentes bibliothèques. –
@Viktor: certes, ceci * est * en grande partie une faute de la bibliothèque. Mais même les implémentations de STL modernes acceptent volontiers un accès hors de portée sur 'operator []' sans énoncer autant d'avertissement, même dans le débogage construit (GCC ...). –
Mais ce n'est pas une fuite de mémoire? Je ne veux pas être arrogant, mais si vous n'écrivez jamais "= new" dans votre code (notez le "="), vous n'obtiendrez pas de fuites de mémoire (oui, shared_ptrs peut se recouper, mais cela arrive très rarement) –