je tente de trouver des memory leak dans mon appli (non MFC). Je fais un
truc du genre (VC++ 7.1):
#include <afxwin.h>
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
Mais je recolte pleins d'erreurs a la compilation. QQ1 pourrait-il
m'aider SVP? Peut etre que vous connaissez un moyen plus efficace
(simple) pour trouver des memory leaks?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Cyrille Szymanski
> #ifdef _DEBUG #define new DEBUG_NEW #endif
Je ne n'ai pas beaucoup utilisé DEBUG_NEW mais il me semble que le ifdef est inutile ici, DEBUG_NEW étant équivalent à new dans le cas d'une release.
Mais je recolte pleins d'erreurs a la compilation. QQ1 pourrait-il m'aider SVP?
Quelles erreurs ?
Peut etre que vous connaissez un moyen plus efficace (simple) pour trouver des memory leaks?
Éviter d'utiliser new, celui qui alloue de la mémoire est celui qui la libère... en gros écrire du code aussi propre que possible pour ce qui est de la gestion des ressources mémoire (c'est aussi vrai pour les autres types de ressources d'ailleurs).
-- Cyrille Szymanski
> #ifdef _DEBUG
#define new DEBUG_NEW
#endif
Je ne n'ai pas beaucoup utilisé DEBUG_NEW mais il me semble que
le ifdef est inutile ici, DEBUG_NEW étant équivalent à new dans
le cas d'une release.
Mais je recolte pleins d'erreurs a la compilation. QQ1 pourrait-il
m'aider SVP?
Quelles erreurs ?
Peut etre que vous connaissez un moyen plus efficace (simple) pour trouver
des memory leaks?
Éviter d'utiliser new, celui qui alloue de la mémoire est celui
qui la libère... en gros écrire du code aussi propre que possible
pour ce qui est de la gestion des ressources mémoire (c'est aussi
vrai pour les autres types de ressources d'ailleurs).
Je ne n'ai pas beaucoup utilisé DEBUG_NEW mais il me semble que le ifdef est inutile ici, DEBUG_NEW étant équivalent à new dans le cas d'une release.
Mais je recolte pleins d'erreurs a la compilation. QQ1 pourrait-il m'aider SVP?
Quelles erreurs ?
Peut etre que vous connaissez un moyen plus efficace (simple) pour trouver des memory leaks?
Éviter d'utiliser new, celui qui alloue de la mémoire est celui qui la libère... en gros écrire du code aussi propre que possible pour ce qui est de la gestion des ressources mémoire (c'est aussi vrai pour les autres types de ressources d'ailleurs).
-- Cyrille Szymanski
korchkidu
Cyrille Szymanski wrote:
Je ne n'ai pas beaucoup utilisé DEBUG_NEW mais il me semble que le ifdef est inutile ici, DEBUG_NEW étant équivalent à new dans le cas d'une release.
Oups, en effet. En fait, je fais d'autre trucs dedans c'est pour ca...
Quelles erreurs ?
Des erreurs specifiques a visual dans xdebug.h notamment (comme de redefinition, ou des non-definitions....)
Éviter d'utiliser new,
uh?
celui qui alloue de la mémoire est celui qui la libère...
re-uh?
en gros écrire du code aussi propre que possible pour ce qui est de la gestion des ressources mémoire (c'est aussi vrai pour les autres types de ressources d'ailleurs).
hehe, merci du conseil...;)
K.
Cyrille Szymanski wrote:
Je ne n'ai pas beaucoup utilisé DEBUG_NEW mais il me semble que
le ifdef est inutile ici, DEBUG_NEW étant équivalent à new dans
le cas d'une release.
Oups, en effet. En fait, je fais d'autre trucs dedans c'est pour ca...
Quelles erreurs ?
Des erreurs specifiques a visual dans xdebug.h notamment (comme de
redefinition, ou des non-definitions....)
Éviter d'utiliser new,
uh?
celui qui alloue de la mémoire est celui
qui la libère...
re-uh?
en gros écrire du code aussi propre que possible
pour ce qui est de la gestion des ressources mémoire (c'est aussi
vrai pour les autres types de ressources d'ailleurs).
Je ne n'ai pas beaucoup utilisé DEBUG_NEW mais il me semble que le ifdef est inutile ici, DEBUG_NEW étant équivalent à new dans le cas d'une release.
Oups, en effet. En fait, je fais d'autre trucs dedans c'est pour ca...
Quelles erreurs ?
Des erreurs specifiques a visual dans xdebug.h notamment (comme de redefinition, ou des non-definitions....)
Éviter d'utiliser new,
uh?
celui qui alloue de la mémoire est celui qui la libère...
re-uh?
en gros écrire du code aussi propre que possible pour ce qui est de la gestion des ressources mémoire (c'est aussi vrai pour les autres types de ressources d'ailleurs).
hehe, merci du conseil...;)
K.
Cyrille Szymanski
>> Éviter d'utiliser new,
uh?
celui qui alloue de la mémoire est celui qui la libère...
re-uh?
Je voulais dire par là qu'il y a quelques principes qui permettent de limiter les fuites de mémoire, les erreurs sur les pointeurs etc. Ça peut s'avérer payant.
-- Cyrille Szymanski
>> Éviter d'utiliser new,
uh?
celui qui alloue de la mémoire est celui qui la libère...
re-uh?
Je voulais dire par là qu'il y a quelques principes qui permettent de
limiter les fuites de mémoire, les erreurs sur les pointeurs etc.
Ça peut s'avérer payant.
celui qui alloue de la mémoire est celui qui la libère...
re-uh?
Je voulais dire par là qu'il y a quelques principes qui permettent de limiter les fuites de mémoire, les erreurs sur les pointeurs etc. Ça peut s'avérer payant.
-- Cyrille Szymanski
Arnaud Debaene
korchkidu wrote:
Éviter d'utiliser new,
uh?
celui qui alloue de la mémoire est celui qui la libère...
re-uh?
Quelques grandes idées : - utiliser la STL. - utiliser les smarts-pointers (boost::shared_ptr notamment - voire www.boost.org) - utiliser l'idiome RAII, autrement dit allouer le maximum de choses sur la pile, pas sur le tas.
Avec ces principes, il est possible d'écrire son code sans jamais devoir faire un delete manuellement (quasiement).
Arnaud MVP - VC
korchkidu wrote:
Éviter d'utiliser new,
uh?
celui qui alloue de la mémoire est celui
qui la libère...
re-uh?
Quelques grandes idées :
- utiliser la STL.
- utiliser les smarts-pointers (boost::shared_ptr notamment - voire
www.boost.org)
- utiliser l'idiome RAII, autrement dit allouer le maximum de choses sur la
pile, pas sur le tas.
Avec ces principes, il est possible d'écrire son code sans jamais devoir
faire un delete manuellement (quasiement).
celui qui alloue de la mémoire est celui qui la libère...
re-uh?
Quelques grandes idées : - utiliser la STL. - utiliser les smarts-pointers (boost::shared_ptr notamment - voire www.boost.org) - utiliser l'idiome RAII, autrement dit allouer le maximum de choses sur la pile, pas sur le tas.
Avec ces principes, il est possible d'écrire son code sans jamais devoir faire un delete manuellement (quasiement).
Arnaud MVP - VC
Korchkidu
Arnaud Debaene wrote:
Quelques grandes idées : - utiliser la STL. - utiliser les smarts-pointers (boost::shared_ptr notamment - voire www.boost.org) - utiliser l'idiome RAII, autrement dit allouer le maximum de choses sur la pile, pas sur le tas.
Avec ces principes, il est possible d'écrire son code sans jamais devoir faire un delete manuellement (quasiement).
Merci pour les conseils. Et pour les memory leaks, vous faites comment???
K.
Arnaud Debaene wrote:
Quelques grandes idées :
- utiliser la STL.
- utiliser les smarts-pointers (boost::shared_ptr notamment - voire
www.boost.org)
- utiliser l'idiome RAII, autrement dit allouer le maximum de choses sur la
pile, pas sur le tas.
Avec ces principes, il est possible d'écrire son code sans jamais devoir
faire un delete manuellement (quasiement).
Merci pour les conseils. Et pour les memory leaks, vous faites comment???
Quelques grandes idées : - utiliser la STL. - utiliser les smarts-pointers (boost::shared_ptr notamment - voire www.boost.org) - utiliser l'idiome RAII, autrement dit allouer le maximum de choses sur la pile, pas sur le tas.
Avec ces principes, il est possible d'écrire son code sans jamais devoir faire un delete manuellement (quasiement).
Merci pour les conseils. Et pour les memory leaks, vous faites comment???
K.
adebaene
Korchkidu wrote:
Arnaud Debaene wrote:
> Quelques grandes idées : > - utiliser la STL. > - utiliser les smarts-pointers (boost::shared_ptr notamment - voire
> www.boost.org) > - utiliser l'idiome RAII, autrement dit allouer le maximum de
choses sur la
> pile, pas sur le tas. > > Avec ces principes, il est possible d'écrire son code sans jamais
devoir
> faire un delete manuellement (quasiement). Merci pour les conseils. Et pour les memory leaks, vous faites
comment???
Quand tu utilises ses principes, tu n'en a plus :-)
Sinon, _CrtDumpMemoryLeaks et _CrtMemDifference sont généralement assez utiles.
Arnaud MVP - VC
Korchkidu wrote:
Arnaud Debaene wrote:
> Quelques grandes idées :
> - utiliser la STL.
> - utiliser les smarts-pointers (boost::shared_ptr notamment - voire
> www.boost.org)
> - utiliser l'idiome RAII, autrement dit allouer le maximum de
choses sur la
> pile, pas sur le tas.
>
> Avec ces principes, il est possible d'écrire son code sans jamais
devoir
> faire un delete manuellement (quasiement).
Merci pour les conseils. Et pour les memory leaks, vous faites
comment???
Quand tu utilises ses principes, tu n'en a plus :-)
Sinon, _CrtDumpMemoryLeaks et _CrtMemDifference sont généralement
assez utiles.
> Quelques grandes idées : > - utiliser la STL. > - utiliser les smarts-pointers (boost::shared_ptr notamment - voire
> www.boost.org) > - utiliser l'idiome RAII, autrement dit allouer le maximum de
choses sur la
> pile, pas sur le tas. > > Avec ces principes, il est possible d'écrire son code sans jamais
devoir
> faire un delete manuellement (quasiement). Merci pour les conseils. Et pour les memory leaks, vous faites
comment???
Quand tu utilises ses principes, tu n'en a plus :-)
Sinon, _CrtDumpMemoryLeaks et _CrtMemDifference sont généralement assez utiles.
Arnaud MVP - VC
Jean-Claude
petit programme bien utile pour des problèmes de memory leak...
GlowCode (gcSetup.exe)
"Korchkidu" a écrit dans le message de news:4219e16d$
Bonjour,
je tente de trouver des memory leak dans mon appli (non MFC). Je fais un truc du genre (VC++ 7.1):
#include <afxwin.h> #ifdef _DEBUG #define new DEBUG_NEW #endif
Mais je recolte pleins d'erreurs a la compilation. QQ1 pourrait-il m'aider SVP? Peut etre que vous connaissez un moyen plus efficace (simple) pour trouver des memory leaks?
Merci d'avance, K.
petit programme bien utile pour des problèmes de memory leak...
GlowCode (gcSetup.exe)
"Korchkidu" <korch_ki_du@yahoo.fr> a écrit dans le message de
news:4219e16d$1@epflnews.epfl.ch...
Bonjour,
je tente de trouver des memory leak dans mon appli (non MFC). Je fais un
truc du genre (VC++ 7.1):
#include <afxwin.h>
#ifdef _DEBUG
#define new DEBUG_NEW
#endif
Mais je recolte pleins d'erreurs a la compilation. QQ1 pourrait-il
m'aider SVP? Peut etre que vous connaissez un moyen plus efficace
(simple) pour trouver des memory leaks?
petit programme bien utile pour des problèmes de memory leak...
GlowCode (gcSetup.exe)
"Korchkidu" a écrit dans le message de news:4219e16d$
Bonjour,
je tente de trouver des memory leak dans mon appli (non MFC). Je fais un truc du genre (VC++ 7.1):
#include <afxwin.h> #ifdef _DEBUG #define new DEBUG_NEW #endif
Mais je recolte pleins d'erreurs a la compilation. QQ1 pourrait-il m'aider SVP? Peut etre que vous connaissez un moyen plus efficace (simple) pour trouver des memory leaks?
Merci d'avance, K.
Cyrille Szymanski
On 2005-02-22, Korchkidu a écrit:
Avec ces principes, il est possible d'écrire son code sans jamais devoir faire un delete manuellement (quasiement).
Merci pour les conseils. Et pour les memory leaks, vous faites comment???
Tiens, personne n'a proposé d'utiliser un garbage collector...
-- Cyrille Szymanski
On 2005-02-22, Korchkidu <korch_ki_du@yahoo.fr> a écrit:
Avec ces principes, il est possible d'écrire son code sans jamais devoir
faire un delete manuellement (quasiement).
Merci pour les conseils. Et pour les memory leaks, vous faites comment???
Tiens, personne n'a proposé d'utiliser un garbage collector...
Avec ces principes, il est possible d'écrire son code sans jamais devoir faire un delete manuellement (quasiement).
Merci pour les conseils. Et pour les memory leaks, vous faites comment???
Tiens, personne n'a proposé d'utiliser un garbage collector...
-- Cyrille Szymanski
Aurélien REGAT-BARREL
> Merci pour les conseils. Et pour les memory leaks, vous faites comment???
Récemment je suis tombé sur ça: http://wyw.dcweb.cn/leakage.htm mais j'ai pas testé. Jusque là j'ai utilisé les possibilités de la CRT: http://msdn.microsoft.com/library/en-us/vsdebug/html/vxconDetectingIsolatingMemoryLeaks.asp http://msdn.microsoft.com/library/en-us/vsdebug/html/_core_Using_C_Run2dTime_Library_Debugging_Support.asp Mais comme on te l'a dit, si tu utilises les smart pointers, la STL et le RAII (new dans les constructeurs, delete dans les destructeurs), tu peux presque faire confiance les yeux fermés à ton code.
-- Aurélien REGAT-BARREL
> Merci pour les conseils. Et pour les memory leaks, vous faites
comment???
Récemment je suis tombé sur ça:
http://wyw.dcweb.cn/leakage.htm
mais j'ai pas testé. Jusque là j'ai utilisé les possibilités de la CRT:
http://msdn.microsoft.com/library/en-us/vsdebug/html/vxconDetectingIsolatingMemoryLeaks.asp
http://msdn.microsoft.com/library/en-us/vsdebug/html/_core_Using_C_Run2dTime_Library_Debugging_Support.asp
Mais comme on te l'a dit, si tu utilises les smart pointers, la STL et le
RAII (new dans les constructeurs, delete dans les destructeurs), tu peux
presque faire confiance les yeux fermés à ton code.
> Merci pour les conseils. Et pour les memory leaks, vous faites comment???
Récemment je suis tombé sur ça: http://wyw.dcweb.cn/leakage.htm mais j'ai pas testé. Jusque là j'ai utilisé les possibilités de la CRT: http://msdn.microsoft.com/library/en-us/vsdebug/html/vxconDetectingIsolatingMemoryLeaks.asp http://msdn.microsoft.com/library/en-us/vsdebug/html/_core_Using_C_Run2dTime_Library_Debugging_Support.asp Mais comme on te l'a dit, si tu utilises les smart pointers, la STL et le RAII (new dans les constructeurs, delete dans les destructeurs), tu peux presque faire confiance les yeux fermés à ton code.
