Salut!
 
Je faisias quelques tests ce matin, car j'ai une appli graphique qui "fuit" a priori! En tout cas, elle plante assez rapidement orsqu'elle s'exécute sous Win98, mais elle marche parfaitement sous Win2000 et WinXP!
 
Bref, j'essaie de trouver des moyens pour trouver ces fuites, à l'aide d'outils annexes!
 
Alors, j'ai voulu essayer Process Viewer. Celui ci me permet de voir, a priori, en temps réel, la mémoire utilisée par chacun des process (zone appelées Working Set et Heap Usage)
 
Alors, juste pour voir (je la fais court), j'essaie d'exécuter la fonction suivante, et de regarder l'état de mon appli avant et après :
 
void CTestingGraphicsView::OnTest()  
{
  // TODO: Add your command handler code here
  const int NUM = 102400;
  CPen myPen[NUM];
}
 
Et là stupéfaction : avant exécution, mon Heap Usage est de 192ko
Après la première exécution, il est de 984 ko, puis, à chaque fois que je réexcute la fonction (tout en laisant l'appli ouverte : je le fais à l'aide d'un bouton), le Heap Usage reste à 984ko.
 
Par contre, si je fais un MyClass myClass[NUM], là tout redescend à 192ko à chaque fois!
 
Sinon, si je mets NUM à 10240 au lieu de 102400, le Heap Usage augmente à la premiere exécution de la fonction, mais seulement à 264ko.
 
Bref, tout celà me laisse perplexe!
 
Ce que j'aime pas, c'est que dans la référence MSDN, ils ne sont pas vraiment transparents sur ce qu'il se passe, donc, c'est aps facile de vraiment comprendre et de maitriser son sujet!!
 
Comment peut on expliquer ça?

il existe des outils pour tracker les memory leak, qui sont capables de te dire quelle variable n'est pas désallouée. (mais là tt de suite me souviens pas de nom..)

De toute facon, quel interet d'allouer 102400 CPen.
Si tu as envie de faire des programmes qui bouffent tes ressources, libre a toi, mais sinon, je ne pourrais m'empécher de penser qu'il y a probablement plus optimal.
Et si ca deconne sous win98, c'est probablement parce que tu depasse le maximum autorise.
A+,

 
L'intéret d'allouer 104200 CPen? Bah aucun, si ce n'est de faire apparaitre la moindre fuite mémoire (qui est alors démultipliée)!
 
Sinon, depuis le temps où j'avais posté ce message, j'ai pu avancer, et en fait, je me rends compte que Win98 pose certains problemes avec certaines méthodes de la MFC. Par exemple, il eut y avoir des fuites de mémoire avec un BitBlt si le DC temporaire n'est pas détruit à la main!
 
Voici un autre exemple :
 
http://www.codeguru.com/mfc/comments/35190.shtml
 
Le seul probleme, c que je n'ai pas Win98 chez moi, donc, je peux pas  vraiment tester sou cet environnement, alors que sous WinXP et win 2k, tout marche nickel !

euh, ca me revient boundschecker
http://www.compuware.com/products/ [...] bounds.htm

 
Bien sur, c'est parfaitement normal. Si c'etait pas le cas, ca serait plus win98. C'est pas que ca pose certains problemes, c'est que pour programmer sous win98, il y avait certaines contraintes a respecter, contraintes qui ont (pour certaines) disparues avec les evolutions successives de cet OS.
A+,

J'ai lu pas mal de mal sur BoundChecker, question de rapport prestation/prix (car il parait que ca vaut super cher) et surtout, je suis tombé récemmment sur un PDF qui expliquait comment obtenir un résultat similaire "a la main" en faisant une "photographie" de la pile d'exécution des fonctions avant et apres appel! (Mais j'ai pas testé)
 
Merci en tout cas pour l'effort!

Bohem GC pour tracker gratuitement les memory leak.
 
Valgrind pour tester de façon très poussée la validité de tes programmes ( utilisation de mémoire non allouée, memory leak à la sortie du programme, buffer overflow, utilisation du cache L1, L2 ... )

Merci beaucoup.
 
En fait, pour ma part, j'ai toujours utilisé dbmon.exe, mais bon, il ne détecte pas tout, et encore moins les fuites mémoire dues a MFC. (Mais bon, ct déja mieux que rien)

Bound checker, j'ai pas mal utilisé, et c'est un excellent outil. Hélas cher.
A+,

 
  Mais à vrai dire
1- je ne connais pas le prix
2- c'est le seul que j'ai utilisé
 
Mais c'est extremement pratique..