Discussion :

[kipgon]

Bonjour à tous,

J'ai un code de calcul qui a manifestement de gros problèmes de mémoires. En effet, quand je fais un décompte "grossier" des données utilisées par ce dernier et que je compare à ce que me donne le gestionnaire de ressources Windows, il semble que je consomme bien d'avantage que je ne le croyais.

Pouvez-vous donc me dire lesquelles des grandeurs suivantes seront désallouées à la sortie de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

func()

? Lesquelles ne le seront pas ? Et pourquoi ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
void func()
{
    vector<double > vec_var;
    vector<double* > vec_ptr;
    double a = 1.0;
    double* b = nullptr;
    double* c = &a;
    double &d = a;
 
    for ( int i = 0; i<10000; i++)
    {
        vec_var.push_back(a);
        vec_ptr.push_back(&a);
    }
}

A priori

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

vec_var

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

a

le sont mais je suis pris d'un doute pour les autres car je viens de découvrir que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

vec_ptr

ne l'est pas... Vous confirmez ?

Merci d'avance pour votre aide

[Bousk]

Tu n'as aucune allocation dynamique* donc tout est désalloué correctement. Pourquoi crois-tu le contraire ?

* les allocations dynamiques internes à vector sont correctement gérées par vector.

[kipgon]

Mince je viens de refaire mon essai et je me rend compte que c'est le vec_ptr.reserve(1000) que je faisait dans la fonction qui cause la non-désallocation de la mémoire... Pourquoi cela d'ailleurs ?

J'ai effectivement lu à droite à gauche qu'il n'y avait que les allocations dynamiques qui causaient des fuites de mémoires. Je n'en utilise aucune (mis à part celles incluent dans les vector bien sur) alors cela m'étonne que mes fuites viennent de la . Je peux toutefois me tromper dans mon évaluation "grossière" mais j'en doute car comme c'est un code de calcul, ce qui prend de l'espace c'est un gros volume de données de même type facile à comptabiliser .

J'ai aussi lu qu'un clear() sur un vector ne désallouait pas la mémoire même si cela réduisait la taille. Est ce vrai ? Y a-t-il d'autres "pièges" de ce type qui peuvent monopoliser de la RAM inutilement jusqu'à la fin du programme ?

Merci beaucoup.

[Bousk]

- reserve ne cause pas plus de fuite mémoire
- clear est appelé dans le destructeur de vector et se charge bien évidemment de désallouer la mémoire
- ton évaluation grossière est fausse, on peut difficilement faire moins précis que "regarder le gestionnaire des tâches" pour évaluer la mémoire sous Windows
Si tes sources prétendent vraiment cela, changes-en.

[kipgon]

Ouch ... c'est ce qui s'appelle se faire envoyer paitre...

Mes sources en matière de c++ sont en grande partie des forums et ne sont donc pas des références j'en conviens. Faut il pour autant cesser d'utiliser des forums ?

Une méthode, peut être, pour dénicher les fuites mémoires d'un programme ou pour faire une meilleure estimation de la consommation d'un programme ?

Voici ce que j'avais lu sur clear() :
http://stackoverflow.com/questions/1...d-upon-a-clear

[bacelar]

Sous Windows, il y a les compteurs de performance et la C-Runtime en débug pour avoir des choses bien plus pertinentes que le "gestionnaire des tâches".