Version imprimable
Hello,
Supposons que j'ai un programme qui, dés qu'un malloc a échoué, quitte avec exit(1). Je me demandais simplement de ce que devenait la mémoire qui avait été alouée précédement?
Faut-il libérer cette mémoire ou bien ca se fait automatiquement?
Merci d'avance ;)
Sur un système évolué, la mémoire appartient au processus, et est libéré quand le processus se termine.
Sur des systèmes embarqués, ce n'est pas dit...
Ok donc sur un système non embarqué (type ordinateur linux/windows quelconque), la mémoire est bien libérée automatiquement ? Car si ce n'est pas le cas, il faudrait en quelque sorte stocker tous les pointeurs qui ont été alloué dans une sorte de variable globale (tableau) et les libérer lorsqu'on souhaite quitter le programme prématurément...
J'ai du mal a comprendre, lorsqu'on fait un malloc, on a toujours insisté sur la necessité de faire un free sous peine de garder une portion de mémoire réservée pour rien une fois le programme terminé... Or, que l'on quitte un programe prématurément ou qu'il se termine normalement, il me semble que ces deux situations sont équivalentes, et que donc si on doit absolument libérer la mémoire lorsque le programme se termine normalement, il semble logique qu'il faille aussi la libérer lorsqu'on le quitte prématurément...
Y aurait-il quelque chose qui m'échappe?
Cela fait partie d'une bonne habitude de programmation à savoir, libérer ce qu'on a alloué !Citation:
Envoyé par vinzzzz
Oui bien sur... Mais si je dois libérer ma mémoire lorsque je quitte un programme brutalement, ca nécéssite tout de même de mettre en place une structure adaptée pour faire ca... Tandis que si elle est automatiquement libérée, on peut s'en passer.
Ce n'est peut-être pas le cas pour tous les systèmes, surtout si tu donnes dans la portabilité, je pense que c'est un point à prendre en considération !Citation:
Envoyé par vinzzzz
et de plus suivant le système de gestion de l'OS, la mémoire libérée lorsqu'un processus meure n'est pas forcément non plus réellement libérée de suite...
En fait, le fond du problème, est pourquoi compter sur quelqu'un d'autre quand on peut le faire soi-même ?
De plus, c'est une bonne habitude à prendre, car, (et il suffit pour s'en rendre compte d'avoir assez longtemps utilisé des softs sous Windows, qui pour beaucoup ne sont pas "safe" de ce côté-là), au départ, c'est juste la mémoire qu'on voudrait libérer, mais il peut y avoir des sockets, des liaisons avec des BD, etc etc...
Comme disait Franck.H c'est de la bonne pratique, c'est comme fermer une parenthèse ouverte.. Symétrique et logique...
En théorie, et pour du code 'jetable', oui.Citation:
Envoyé par vinzzzz
Mais dans l'industrie, le code validé, ça coûte cher. Quand on écrit un nouveau programme, on cherche à réutiliser ce qui a été fait précédemment, et si on écrit du code nouveau, on cherche à ce qu'il soit réutilisable. Donc on travaille avec des 'briques' logicielles autonomes qui ont leur propres 'constructeurs'/'destructeurs' gérant proprement et efficacement la mémoire. Les détails ne sont pas visibles de l'utilisateur, mais ils doivent être conçus et codés correctement, car on ne sait pas d'avance quelles seront les conditions d'utilisation.
Théorie : http://emmanuel-delahaye.developpez.com/tad.htm
Réalité : http://emmanuel-delahaye.developpez.com/clib.htm
Oui tout ce que vous dites semble bien logique... C'est clair que quitter un programme en laissant des variables alouées, même si ca passe parfois, c'est pas super propre...
Ca complique pas mal le code: je quitte mon programme, il faut donc retrouver tous les pointeurs qui ont été alloués et qui doivent donc être libérés. Pour faire ca, je vois pas d'autre solution que de faire une variable globale (ou statique même), type liste de void*, qui va stocker tous les pointeurs de base ayant été aloués, et sur laquelle on bouclera une fois que le programme va se terminer brusquement.
Ce type de solution vous parait-elle honorable? Ca me semble assez chiant et lourd a gérer (il faudrait alors retirer les pointeurs désaloués au cours du programme), mais l'autre solution que je vois, ie. retourner pour chacune de mes fonctions un flag et les tester a chaques fois, me semble également assez compliquée et nécessitant pas mal de changements (mes fonctions renvoient parfois des résultats etc..)..
Bref si vous avez une solution miracle n'hésitez pas :yaisse2:
Déjà répondu. C'est une question d'organisation structurée du code. Tu as lu les liens ? Il y a un moment où il faut arrêter de bricoler et se mettre coder sérieusement et avec méthode...Citation:
Envoyé par vinzzzz
C'est bien ce que j'essaye de faire. ;)
Dans ma pratique, si une fonction ne parvient pas à faire une allocation dynamique, je libère la mémoire précédamment allouée dans le corps de la fonction en cours et renvoie un code d'erreur explicite à la fonction appelante qui aura la responsabilité de réagir comme elle l'entend à cet échec (éventuellement réallouer plus tard, réallouer plus petit, utiliser un pool de mémoire pré-alloué pour les cas d'urgences, etc.).
Si la fonction appelante ne sait elle-même pas comment réagir à cet échec, elle renvoie un code d'erreur à la fonction qui l'as appelée, et ainsi de suite jusqu'à main() qui décidera si il est nécessaire de quitter le programme. C'est très schématique et je n'ai pas l'expérience des très gros projets où j'imagine que cela n'est pas toujours aussi simple. Chez moi en tout cas, seul main() est autorisé à quitter le programme. Cette stratégie me permet d'assurer que toute les resources ont été libérées au moment où le programme quitte.
Thierry
Oui ca me semble être la méthode la plus propre...
En revanche, devoir tester à chaque fois dans chaque fonction appelante un code d'erreur (sachant que l'erreur à déja été repérée dans le code, là ou l'allocation a échouée) peut grandement ralentir le programme... En tout cas dans les aplications que je développe (type numériques) qui réalisent des millions de fois certains enchainements d'appels de fonctions.
Mais bon si on veux un code fiable, robuste et portable, on a pas le choix je suppose.
La question ne se pose que dans les phases d'initialisation. Une fois que l'objet est créé, on a plus besoin de tester grand chose...Citation:
Envoyé par vinzzzz
La stratégie habituelle dans les algorithmes temps réel est de limiter le nombre de créations en anticipant au maximum ... Rien que du bon sens ordinaire...
non, on n'a pas le choix..Citation:
Envoyé par vinzzzz
Quant a la vitesse, aucun ralentissement si le code est bien fait...
ne prend pas franchement du temps...Code:
2
Il faut éviter autant que possible les globales. Ma solution et celle que j'utilise quand je fait beaucoup d'allocations lors de la vie du programme, c'est d'utiliser un gestionnaire d'allocations ! On peut s'en faire un soi-même, si c'est fait correctement, le programme libère alors automatiquement la mémoire lors de sa sortie (par return ou un exit). Dans mon cas cela ajoute un peu d'allocation supplémentaire pour la gestion de la liste des adresses allouées mais au prix rentable d'une application propre.Citation:
Envoyé par vinzzzz
Il faut bien tester si la création de l'objet s'est bien déroulée, et renvoyer un flag si ce n'est pas le cas, flag qui devra être testé par toutes les fonctions appelantes.Citation:
Envoyé par Emmanuel Delahaye
Anticiper, bien entendu, mais on a pas toujours le choix.
Oui je sais pas, si F1 appele F2 qui appele F3 puis F4 ... puis FN, et que dans chacune d'entre elles on vérifie la sortie, ca nous donne N tests a répéter des millions de fois... C'est peut être négligeable par ailleurs, je ne sais pas.Citation:
Envoyé par souviron34
Quant aux gestionnaires d'allocations, je connais pas (encore ;) ).
Ca n'existe pas, il faut le faire soi même ou bien en télécharger un comme par exemple sur mon site mais un exercice est bien de s'y mettre et le créer de toutes pièces.Citation:
Envoyé par vinzzzz
Cela peut se faire de différentes façons je suppose, le miens repose sur une liste chaînée qui contient toutes les adresses allouées par le biais des fonctions enveloppes de malloc/calloc/realloc/free qui font parties de la bibliothèque.
C'est la même idée que ce que j'ai décrit plus haut? En quelque sorte, un fichier gestionnaire.c dans lequel il y aura une variable statique contenant les pointeurs aloués.
Ensuite des fonctions qui gèrent cette liste: supression des pointeurs désaloués au cours du programme (ca implique donc de l'appeler avant tout free(p)), ajout des nouveaux pointeurs, et une foncton qui libère le tout?
Je suppose que c'est un peu plus complexe que ca mais est-ce qu'au moins je ne suis pas totalement à coté de la plaque?
Ok ca semble être à peu prés ca donc.Citation:
Envoyé par Franck.H