Discussion :

[Pierre.g]

Bonsoir tout le monde,

Quand une variable est alloué avec malloc et que l'on n'a pas utilisé free(variable);, quand le programme est fermé, la mémoire est-elle bien rendu libre ?

Je pose cette question, car, dans un programme, quand une variable alloué avec malloc doit durée pendant toute l'exécution du programme, peut-on se passer de free même si c'est un peu crados ?

Merci.
A+, Pierre.

[Emmanuel Delahaye]

Quand une variable est alloué avec malloc et que l'on n'a pas utilisé free(variable);, quand le programme est fermé, la mémoire est-elle bien rendu libre ?

Oui. Mais ça ne signifie pas que c'est une Bonne Pratique.

Je pose cette question, car, dans un programme, quand une variable alloué avec malloc doit durée pendant toute l'exécution du programme, peut-on se passer de free même si c'est un peu crados ?

Après les globales, les malloc() sans free(). C'est pour un concours de goretisation ?

http://emmanuel-delahaye.developpez.com/goret.htm

Techniquement, oui, on peut se passer de la libération, mais

• Si on utilise un traqueur de mémoire (valgrind, Purify etc. ), on le pollue avec des libérations manquantes non significatives qui peuvent masquer un réel problème de libération de mémoire.
• Si le code devient réutilisable, il ne gère pas bien la mémoire. Les conséquences peuvent être graves et la correction à postériori plus difficile et plus couteuse.
• Ca m'empêche de dormir se savoir qu'il existe du code bancal comme ça dans la nature...

Bref, le bon sens, c'est de retirer le gros poil que tu as dans la main, et d'écrire du code correct dès le premier jour :

• pas de globales mais des contextes
• un malloc(), un free().

On compte sur toi pour allonger la liste... Ma boule de cristal vient de me dire 'FILE*'...

[koala01]

Salut,

Normalement, toute la mémoire utilisée par un processus quelconque (ton application qui tourne étant à considérer comme un processus) est libérée lorsque le processus est proprement tué...

Donc, oui, de fait, on pourrait très bien se passer de libérer explicitement la mémoire si cela ne faisait pas crado...

Par contre, c'est loin d'être tres bon...

D'abord, il est intéressant de prendre l'habitude de libérer correctement la mémoire allouée dynamiquement à quelque chose dés que tu n'en a plus besoin...

Le cas d'une variable devant "durer aussi longtemps que l'application" n'étant qu'un cas particulier qui mérite d'être traité comme tous les autres...

Il faut bien te dire que, si tu prend la mauvaise habitude de ne pas libérer les variables qui durent aussi longtemps que l'application, tu risques fort de te retrouver à mettre cette habitude en pratique pour celles qui ont une durée de vie clairement limitée... et que c'est à ce moment là que tu finiras par tomber sur un os à un moment ou un autre... (ben oui, meme si le Mb de RAM ne coute plus rien de nos jour, et qu'on en a de plus en plus, ce n'est quand meme pas infini )

De plus, il faut bien savoir que ton application risque très fort d'être, pour une raison ou une autre, interfacée avec d'autres... qui risquent de ne pas tuer le processus de la tienne en temps et en heure... ce qui reportera le problème sur l'application "interfacante"...

Bien que l'exemple que je m'apprete à citer soit plus le fait de VB que du C++, penses à tous les problèmes rencontrés lorsque l'on interface une application de MS (word, excell, outlook) et qu'on ne prend pas la précaution de passer avec le "garbage collector" une fois que l'on n'a plus besoin des applications lancées...

Au fil du temps, tu te trouves avec 5,6...10 processus de l'application... Si pas plus (et qui survient parfois à l'arret de l'application qui les a lancés, d'ailleurs)...le tout, menant à un joli écran bleu si connu sous les versions précédentes...

Le fait de libérer correctement autant de ressources que possible lorsque ton application arrive à son terme, meme si le processus n'est pas correctement tué par l'application qui l'a lancé, permettra d'avoir une meilleur résistance à ce genre de phénomène...

D'ailleurs, quand on y pense bien...

Il y a des chances que ton application soit articulée autour d'une structure de programme du genre de

Code :

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

1
2
3
4
5
6
7
8
9
 
int main()
{
    tontype *tavariable_immortelle;
    tavariable_immortelle=init();
    /*utilisation au gre de l'application */
 
    return 0;
}

Pourquoi travailler comme un cochon, alors qu'il suffirait de rajouter, juste avant le return 0, un appel sous la forme de

Code :

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

1
2
3
 
Libere(tavariable_immortelle);
tavariable_immortelle=NULL;

avec la fonction Libere qui libérerait proprement la mémoire allouée dynamiquement

[Pierre.g]

Merci à vous deux,

"Après les globales, les malloc() sans free(). C'est pour un concours de goretisation ?"
=> j'y ais pensé en faisant ce post

Sinon, je posais ces question principalement pour savoir si ça vidais la mémoire quand le processus se fermais, j'imaginais bien que oui, mais ce n'étais qu'une suposition.

Pour l'absence de free();, je suis d'accord avec vos arguments, faut donc que je ne prenne pas de mauvaise habitudes ...

Merci.
A+, Pierre.

[Lunixinclar]

http://www.gnu.org/software/libc/man...g-after-Malloc