2010-11-27 25 views
0

Le code suivant conduit à une fuite de mémoire:tableau Dynamiquement alloué à l'intérieur std :: liste conduit à memoy fuites

std::list<float*> vertices; 

    float* v; 
    for (int i = 0; i < 50000; i++){ 
     v = new float[3]; 
     v[0] = v[1] = v[2] = 13; 

     vertices.push_back(v); 
    } 

    std::list<float*>::iterator curr; 
    for(curr = vertices.begin(); curr != vertices.end(); curr++) { 
     delete[] *curr; 
    } 

    vertices.clear(); 

Je ne sais pas pourquoi cela se produit, mais je suppose qu'il est connecté à une anomalie de std :: liste. La partie la plus étrange est que si je lance le code plus d'une fois consécutivement, la quantité de mémoire qui fuit ne change pas. Se peut-il que quelque chose me manque vraiment?
Quelqu'un peut-il suggérer une raison à cela? Puis-je résoudre ce problème en changeant seulement la partie destruction du code?

Plus d'informations:
Ceci est une application de mfc. Le code est exécuté sur un bouton. Avant d'appuyer sur le bouton, je vois 15mb dans le gestionnaire de tâches. Après avoir appuyé sur le bouton, je vois 40mb. Le bouton ne fait qu'exécuter ce code.

+0

Pourquoi pensez-vous qu'il y a une fuite de mémoire ici? – ronag

+0

Quelle est la quantité de mémoire qui fuit? – suszterpatt

+0

@ronag, @suszterpatt: Voir modification – Artium

Répondre

6

Vous interprétez mal vos résultats. La "fuite" que vous voyez n'est pas réellement une fuite, mais une pré-allocation, qui est essentiellement où le CRT ou la STL garde de la mémoire allouée au cas où vous en auriez besoin pour une allocation plus rapide.

De plus, vous devriez vraiment, vraiment utiliser des pointeurs auto-relâchés. Ils sont garantis de ne jamais perdre de mémoire, s'ils sont utilisés correctement, et il y a une foule de pointeurs intelligents bien écrits dans Boost ou dans la bibliothèque standard d'un nouveau compilateur. Edit: Le gestionnaire de tâches n'est PAS un moyen fiable de mesurer les allocations/désallocations/etc. Cela n'attribue même pas 25 Mo.

Plus d'édition: Vous n'auriez même pas besoin de vérifier si vous avez utilisé des pointeurs RAII appropriés au lieu de pointeurs bruts.

+0

Y at-il un moyen de désactiver cette fonction? Je veux pouvoir distinguer ce "cache" d'une réelle fuite de mémoire. Je veux voir si cela était le problème dans mon vrai code, ou peut-être que j'en ai une autre, vraie fuite là (ce que j'ai montré ici est seulement ce que je pense être le "down-down" du problème). – Artium

+0

@Artium: vous utilisez généralement du code qui remplace l'allocateur de mémoire par défaut par un code de suivi. C'est facile à utiliser dans le STL au moins. Vous ne devriez pas l'éteindre, car il améliore énormément les performances. Edit: Ou plutôt, vous devriez utiliser un profileur de mémoire réel, pas le gestionnaire de tâches. – Puppy

3

ne vois aucune fuite de mémoire dans votre code ...

Vous devriez vraiment utiliser RAII, et vous auriez pas besoin de vous inquiéter ... et je suppose que std :: vecteur pourrait être un meilleur choix ici puisque vous voulez probablement la mémoire continue ...

par exemple

typedef std::array<float, 3> vec3; 
std::vector<vec3> vertices; 

for (int i = 0; i < 50000; i++) 
{ 
    vec3 v = {13, 13, 13}; 
    vertices.push_back(v); 
} 

vertices.clear();