Discussion :

[dafpp]

Bonjour, quelle est la meilleur manière pour quitter le programme quand il y a une erreur?
Car oui, parfois, de la mémoire est alloué, mais est seulement désaloué à la fin. Et faire une fonction qui désaloue tous les morceaux m'oblige à mettre les variables qui pointe dessus en global.
Donc dans ce cas, qu'est ce qu'il faut faire?
Merci d'avance.

[skeud]

Tout dépend, si c'est un programme one-shot (qui effectue un traitement puis s'arrete) ou non.

Si c'est un one-shot, tu n'as pas trop besoin de t'occuper de libérer la mémoire, elle sera automatiquement libérer lors de l'arret, donc ça règle la question.

Par contre si ce n'est pas un one-shot, tu dois IMPERATIVEMENT libérer la mémoire au fur et à mesure que tes variable ne servent plus.

Dans le cas d'un non one-shot:
Ne jamais utilisé exit(-1); pour quitter le programme, sinon l'utilisateur ne comprendras pas pourquoi il s'est arrété brutalement.
Préfere dans chaque fonction, un code de retour, qui permet de savoir la bonne exécution ou non de cette partie.
Perso, ce que je fais, c'est une fonction qui va libérer la mémoire pour tout les objets rendu inutile après le passage de la fonction, elle sera appelé dans le cadre de la réussite ou non, juste avant le return.


De manière générale, il faut toujours libérer la mémoire au plus proche de la fin d'utilisation d'une variable afin de limiter la consommation de mémoire et les risques de leak.

En espérant que ma réponse t'as aidé

[gerald3d]

...Et faire une fonction qui désaloue tous les morceaux m'oblige à mettre les variables qui pointe dessus en global.
Merci d'avance.

Si tu te sens obligé de déclarer en global c'est que ton architecture logicielle ne doit pas être bien agencée. Pourrais-tu nous montrer ton code, à moins qu'il soit trop long ?

Quant à la réponse de "Skeud", tout est dit .

[Sve@r]

Bonjour, quelle est la meilleur manière pour quitter le programme quand il y a une erreur?

Salut
Si tu demandes "la meilleure" tu auras 500 millions de réponses.
Pour moi, on rentre dans un programme par le main et on en sort par le main. Et donc si une fonction interne bloque pour une raison X ou Y, elle doit se borner à renvoyer l'erreur à l'appelant qui gèrera en conséquence (quitte à lui-aussi arrêter et renvoyer le pb à l'appelant et etc etc jusqu'au main). Donc en fait on ne met jamais de exit() dans une fonction (et on peut même éviter d'en mettre dans le main en remplaçant exit par return, ça marche aussi).

Car oui, parfois, de la mémoire est alloué, mais est seulement désaloué à la fin. Et faire une fonction qui désaloue tous les morceaux m'oblige à mettre les variables qui pointe dessus en global.
Donc dans ce cas, qu'est ce qu'il faut faire?
Merci d'avance.

Tu devrais regarder ma fonction qui recopie stdin dans un char* dans ton topic sur stdin ici car j'y ai intégré une gestion d'erreurs malloc.
Et donc si à un moment donné le malloc échoue, déjà comme j'ai gardé le pointeur précédent je peux le libérer mais en plus je me contente de renvoyer le pb à l'appelant (le main) qui, lui, gère alors la crise.
Mais tout n'est toujours pas aussi simple. Prenons par exemple le cas de 3 buffers. Tu feras un premier malloc que tu vas gérer. Puis un second et tu devras alors gérer le cas du second malloc échoué en n'oubliant pas de libérer alors le premier buffer. Puis idem au 3°. Cela donnerait alors un truc de ce genre

Code c :

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
void fonction()
{
    char *buf1;
    char *buf2;
    char *buf3;
 
    buf1=malloc(...)
    if (buf1 == NULL)
        return;
 
    buf2=malloc(...)
    if (buf2 == NULL)
    {
        free(buf1);
        return;
    }
 
    buf3=malloc(...)
    if (buf3 == NULL)
    {
        free(buf1);
        free(buf2);
        return;
    }
 
    .... // travail
    free(buf1);
    free(buf2);
    free(buf3);
}

Ca reste lisible et dans une philosophie que j'aime bien (commencer par gérer tous les pb puis ensuite coder le travail réel). Mais ca ne plaira pas à certains puristes qui te parleront de redondance des free() et qui rajouteront qu'une fonction void ne doit pas avoir de return (oui oui, le monde de la prog possède aussi son inquisition et son bûcher). On va donc coder différemment pour contenter ces ayatollistes...

Code c :

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
17
18
19
20
21
22
23
int fonction()
{
    char *buf1;
    char *buf2;
    char *buf3;
 
    buf1=malloc(...)
    if (buf1 != NULL)
    {
        buf2=malloc(...)
        if (buf2 != NULL)
        {
            buf3=malloc(...)
            if (buf3 != NULL)
            {
                .... // travail
                free(buf3);
            }
            free(buf2);
        }
        free(buf1);
    }
}

Un code plus pur... mais moins lisible. Et si en plus tu dois gérer 50 ressources, une fois tous les tests faits tu te retrouves à coder complètement à droite de l'écran. Mais ça reste puriste.

Ensuite, tu peux essayer de ruser (comme le voleur dans le donjon de Naheulbeuk). Ca plait pas au barbare qui a peur de Crôm mais ça marche... surtout quand tu utilises judicieusement une instruction peu usitée de par la polémique qu'elle suscite: le "goto". Personnellement moi je dis que ce ne sont pas les outils qui sont mauvais mais la façon dont on s'en sert. Et donc si on s'en sert judicieusement, un bon "goto" bien placé peut améliorer bien des choses. Voyons donc ce que ça donnerait...

Code c :

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
17
18
19
20
int fonction()
{
    char *buf1=NULL;
    char *buf2=NULL;
    char *buf3=NULL;
 
    buf1=malloc(...)
    buf2=malloc(...)
    buf3=malloc(...)
    if (buf1 == NULL  || buf2 == NULL || buf3 == NULL)
        goto clean;
 
    .... // travail
 
    // Nettoyage
    clean:
    free(buf1);
    free(buf2);
    free(buf3);
}

Ca marche parce que soit le pointeur est alloué par malloc soit il est à NULL et free() sur un pointeur NULL reste sans effet.

Voilà différentes façon de résoudre un pb simple. Maintenant chaque pb est différent. L'important c'est que tu essayes d'être simple dans ta façon de faire et que tu arrives à te relire. Et pour ça il y a un truc incontournable: le commentaire...

Si c'est un one-shot, tu n'as pas trop besoin de t'occuper de libérer la mémoire, elle sera automatiquement libérer lors de l'arret, donc ça règle la question.

Argh je supporte pas ce genre de phrase. C'est "je m'en fouts je laisse faire les autres". Jusqu'au jour où tu tombes sur un OS pourri où chacun s'est appuyé sur tous les autres et tu es obligé de le rebooter toutes les 25 minutes...

[gangsoleil]

Si c'est un one-shot, tu n'as pas trop besoin de t'occuper de libérer la mémoire, elle sera automatiquement libérer lors de l'arret, donc ça règle la question.

Non. Tu supposes ici que l'OS fait bien son travail, ce qui n'est pas forcement le cas -- de meme que je suppose que lorsque tu utilises des ressources dans ton programme, tu finiras par les supprimer apres.


Sinon, je me range a peu pres a ce que dit Sve@r : tu alloues et desalloues au fur et a mesure des besoins.

[Franck.H]

+1

Ne jamais supposer, si tu alloues dynamiquement de la mémoire tu la libère toi-même lorsque tu n'en as plus besoin car le reste est trop dépendant du système. D'ailleurs même lorsque tu libère toi-même la mémoire rien ne garantit que ce soit fait immédiatement et je pense que c'est rarement le cas.

[skeud]

Un code plus pur... mais moins lisible. Et si en plus tu dois gérer 50 ressources, une fois tous les tests faits tu te retrouves à coder complètement à droite de l'écran. Mais ça reste puriste.

Perso c'est justement pour ça que j'utilise une fonction qui va s'occuper de la gestion de la memoire:

Pour chaque traitement j'ai une fonction qui alloue les ressources dans une structure.
Une deuxieme qui prend cette structure et effectue le traitement.
Une troisieme qui free tout ce dont je n'ai plus besoin.

C'est peut-être extreme mais au moins j'ai aucun problème de leak, et quand il y en a, c'est hyper facile à resoudre

[Obsidian]

Non. Tu supposes ici que l'OS fait bien son travail, ce qui n'est pas forcement le cas -- de meme que je suppose que lorsque tu utilises des ressources dans ton programme, tu finiras par les supprimer apres.

Merci de le signaler !

De toutes façons, dès lors que ce programme simple fonctionnera, le primo-postant passera en principe à quelque chose de plus compliqué. Donc autant apprendre dès le départ à faire les choses proprement.

[imperio]

Dans le cas d'un non one-shot:
Ne jamais utilisé exit(-1); pour quitter le programme, sinon l'utilisateur ne comprendras pas pourquoi il s'est arrété brutalement.

Je vois pas pourquoi, la fonction atexit existe pour ca, dans la fonction appelee tu peux tres bien faire de l'affichage ou meme gerer la memoire de ton programme si tu l'as centralise (un peu comme tu l'as decrit toi-meme dans ce post :

Perso c'est justement pour ça que j'utilise une fonction qui va s'occuper de la gestion de la memoire:

Pour chaque traitement j'ai une fonction qui alloue les ressources dans une structure.
Une deuxieme qui prend cette structure et effectue le traitement.
Une troisieme qui free tout ce dont je n'ai plus besoin.

).

[skeud]

Alors, perso, la fonction exit, je préfère l'évitée.
Oui elle existe, et non c'est pas forcément top.
Pareil que les goto et autres trucs de ce genre, c'est une bonne pratique de ne les utilisé que lorsqu'il n'y a aucune autres solutions.

Je disais d'éviter d'utiliser exit dans un programme qui n'est pas en one-shot.Du style un progiciel ou juste un petit soft qui possède une interface graphique.

Imagine si en cas d'erreur, ton jeux quitte et ferme tout sans rien te dire au lieu de t'afficher une erreur. C'est pour ça que de base, il vaut mieux ne pas utiliser exit.

Comme précisé plus haut, un programme possède une entrée et une sortie qui est le main et le retour du main.

EDIT: autant pour moi je n'avais pas vu le "at" devant le exit .
Bref, perso je suis pas fan, ces fonctions sont utiles pour coder rapidemment, mais je les aimes pas trop, c'est mieux de gérer exactement la mémoire au plus proche de sont utilisation et non pas lors de la fin du main

[imperio]

Le atexit n'est pas une mauvaise pratique, il est tres utile dans le cas de l'utilisation d'une lib externe, par-exemple la SDL. Apres son initialisation, tu peux tres bien utiliser atexit pour appeler SDL_Quit(). Ca t'evite d'avoir a t'en preoccuper plus tard. Donc je le repete, de mon point de vue, exit est bonne chose (mais a utiliser avec intelligence comme tout le reste).

[Franck.H]

Pareil pour atexit, je l'utilise pour automatiser des tâches en fin de programme

[Neckara]

Non. Tu supposes ici que l'OS fait bien son travail, ce qui n'est pas forcement le cas -- de meme que je suppose que lorsque tu utilises des ressources dans ton programme, tu finiras par les supprimer apres.

Pour la mémoire allouée, si vous avez un OS qui ne la libère pas correctement...
Changez vite d'OS !
En effet, si dès qu'un programme plante ou a une petite fuite de mémoire, la mémoire n'est pas désallouée par l'OS à la fin du programme...
Je ne sais pas comment fonctionne la gestion de la mémoire sous Windows, mais sous Linux, il est impossible que la mémoire ne soit pas libérée à la fin du programme. Ce qui n'empêche pas de libérer soit-même la mémoire

Le atexit n'est pas une mauvaise pratique, il est tres utile dans le cas de l'utilisation d'une lib externe, par-exemple la SDL. Apres son initialisation, tu peux tres bien utiliser atexit pour appeler SDL_Quit(). Ca t'evite d'avoir a t'en preoccuper plus tard. Donc je le repete, de mon point de vue, exit est bonne chose (mais a utiliser avec intelligence comme tout le reste).

Personnellement, le seul endroit où j'utilise exit(), ce sont dans les fonctions (bad_)usage() :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
void usage(const char * command)
{
       fprintf("usage : %s blabla\n", command);
       exit(EXIT_FAILURE);
}
 
int main(int argc, char ** argv)
{
      if( param_pas_valide)
              usage(argv[0] );
 
      return EXIT_SUCCESS;
}

Mais un bibliothèque ne devrait jamais utiliser exit(). C'est à l'utilisateur de décider que faire en cas d'erreurs, il faut dans tous les cas, remonter l'erreur à l'utilisateur.
C'est aussi à l'utilisateur de décider que faire après qu'il en ai terminé avec la bibliothèque : quitter le programme ? relancer ? se faire recouvrir ?

Appeler exit() dans une fonction n'a donc pas vraiment de raison d'être. Utiliser atexit() devrait alors être très rare.

D'ailleurs la SDL déconseille l'utilisation de atexit() :

Note: L'utilisation de atexit peut être parfaite dans de petits programmes, mais les utilisateurs plus avancés devraient clore la SDL sans son utilisation. De plus, l'utilisation de atexit dans une bibliothèque est une manière sure de provoquer un crash à cause du code chargé dynamiquement.

.

[imperio]

Pour la mémoire allouée, si vous avez un OS qui ne la libère pas correctement...
Changez vite d'OS !
En effet, si dès qu'un programme plante ou a une petite fuite de mémoire, la mémoire n'est pas désallouée par l'OS à la fin du programme...
Je ne sais pas comment fonctionne la gestion de la mémoire sous Windows, mais sous Linux, il est impossible que la mémoire ne soit pas libérée à la fin du programme. Ce qui n'empêche pas de libérer soit-même la mémoire

Sous windows (depuis windows 98) comme sous linux, la memoire est liberee a la fin du programme. Cependant, si c'est de l'embarque, il y a peu de chance pour que la memoire soit liberee automatiquement et il n'est pas question de changer d'os donc faut faire avec !

Mais un bibliothèque ne devrait jamais utiliser exit(). C'est à l'utilisateur de décider que faire en cas d'erreurs, il faut dans tous les cas, remonter l'erreur à l'utilisateur.
C'est aussi à l'utilisateur de décider que faire après qu'il en ai terminé avec la bibliothèque : quitter le programme ? relancer ? se faire recouvrir ?

Les libs ne doivent pas utiliser exit, on est bien d'accord. C'est l'utilisateur qui l'appelle s'il en a envie, certainement pas une fonction de la lib. L'avantage des libs c++ c'est qu'elles peuvent utiliser les exceptions.

Pour le atexit avec la sdl, il me semblait que c'etait justement dans un tuto sur leur site que je l'avais vu...

[Kannagi]

Je suis plutôt sceptique qu'un OS ne libère pas la mémoire d'un programme qui se ferme , vu que si un programme se ferme sans libéré la mémoire , que fait OS de la mémoire non libéré ? sachant que cette mémoire ne fait partie a aucun processus courant je pense qu'un OS considérera alors cette mémoire comme libre.

Cependant, si c'est de l'embarque, il y a peu de chance pour que la memoire soit liberee automatiquement et il n'est pas question de changer d'os donc faut faire avec !

Certe pas tout le monde est d'accord ce que signifie embarqué , mais pour moi embarqué veut dire sans OS donc pas de malloc et donc mémoire libéré ou pas perd tout son sens (vu qu'on a accès a la totalité de la mémoire).

[Neckara]

Sous windows (depuis windows 98) comme sous linux, la memoire est liberee a la fin du programme. Cependant, si c'est de l'embarque, il y a peu de chance pour que la memoire soit liberee automatiquement et il n'est pas question de changer d'os donc faut faire avec !

S'il y a un OS, ce n'est plus vraiment de "l'embarqué à 100%".

Dans "l'embarqué pur", le démarrage du programme se fait par un "reset"/"init" et le programme ne quitte que lorsqu'on éteint le micro-contrôleur donc la "libération de la mémoire" est faite lors du "reset"/"init".

Dès qu'on a un OS, il va être chargé de la gestion de la mémoire, et normalement, il associera à chaque processus un "espace mémoire" ou une "page". Lorsque le processus est détruit, les "espaces mémoire" ou les pages seront libérés.

Après, dans le cas de l'embarqué + programmation mobile + entre les deux, c'est presque du cas par cas.
Il faut voir si la norme est respectée de partout, quels sont les spécificités, les contraintes (allocation dynamique envisageable ?), comment intégrer notre programme... Bref, c'est très spécifique.
Donc dans ce cas là, on adaptera le main() en conséquence.

[gangsoleil]

Pour la mémoire allouée, si vous avez un OS qui ne la libère pas correctement...
Changez vite d'OS !

Oui, aie. Et non, je ne changerai pas d'OS, et la raison en est tres simple : ce n'est pas moi qui decide, c'est le client.

Et des clients, j'en connais sous pleins d'OS (au moins 4 Unix et 3 Linux), qui sont eux-meme divises en plein de versions, pas a jour (pour pleins de raisons la aussi) voir tres anciennes.

Apres, si tu as un programme simple, monolithique, qui va tourner une seule fois, oui, il y a des chances pour que ca se passe bien -- mais je ne peux pas en etre certain.

Ici, il y a de fortes chances pour qu'une sortie brutale ne soit pas problematique, et que de toute maniere la machine soit rebootee le soir meme. Mais quitte a donner des conseils, je prefere donner des conseils qui seront applicables dans tous les contextes, et qui ne seront pas obsoletes des que le developpeur aura un peu progresse.

Oui, on peut tout a fait utiliser scanf pour lire des entrees clavier, mais non, ce n'est pas une bonne idee dans la vraie vie. Est-ce que pour autant on doit conseiller aux debutants d'utiliser scanf, et lorsqu'ils feront des vrais programmes alors on leur apprendra que non c'est mal ? Pas pour moi.

Donc oui, je conseille d'allouer et de liberer la memoire au fur et a mesure des besoins.
Quant a l'utilisation de atexit, elle ne repond pas, dans beaucoup de cas, au besoin de liberer la memoire des qu'on a fini de s'en servir. C'est pour ca que je ne m'en sers jamais.

[Bktero]

mais pour moi embarqué veut dire sans OS donc pas de malloc et donc mémoire libéré ou pas perd tout son sens (vu qu'on a accès a la totalité de la mémoire).

S'il y a un OS, ce n'est plus vraiment de "l'embarqué à 100%".

C'est quoi ces affirmations pourries, les gars ?

Il ya des OS pour l'embarqué, pour des micro-contrôleurs qui vont tourner dans des équipements 24/7. Perso, je bosse avec Keil RTX et FreeRTOS sur des Cortex M3/M4, ça tourne dans des équipements qu'on peut qualifier d'enfoui, c'est de l'embarqué à 100%. La gestion de l'allocation dynamique est au choix de l'OS comme toujours, l'embarqué n'échappe pas à cette règle. Vous pouvez par exemple dans FreeRTOS regarder les différentes techniques d'allocation : http://www.freertos.org/a00111.html

Le point qui change est le sens qu'on donne à "sortie du programme". Si on sort du programme, je présume que la plupart des systèmes redémarrent, donc la mémoire est libérée, on peut en être certains ^^

[Metalman]

En gros, pour dafpp :

Renseigne-toi sur le/les OS sur le/lesquel(s) ton appli va tourner....

- S'il gère la libération mémoire durant un exit(), alors utilise-le... (pour reprendre des arguments déjà vus : pourquoi se mettre des contraintes inutiles ?)

- Si tu ne sais pas, ou qu'il ne le fait pas, fais des retours de fonctions avec des valeurs d'erreur jusqu'au main() qui fera de même... et n'oublie pas d'écrire l'erreur quelque part

[Neckara]

C'est quoi ces affirmations pourries, les gars ?

Il ya des OS pour l'embarqué, pour des micro-contrôleurs qui vont tourner dans des équipements 24/7. Perso, je bosse avec Keil RTX et FreeRTOS sur des Cortex M3/M4, ça tourne dans des équipements qu'on peut qualifier d'enfoui, c'est de l'embarqué à 100%. La gestion de l'allocation dynamique est au choix de l'OS comme toujours, l'embarqué n'échappe pas à cette règle. Vous pouvez par exemple dans FreeRTOS regarder les différentes techniques d'allocation : http://www.freertos.org/a00111.html

Le point qui change est le sens qu'on donne à "sortie du programme". Si on sort du programme, je présume que la plupart des systèmes redémarrent, donc la mémoire est libérée, on peut en être certains ^^

Du point de vue de la programmation (car c'est bien de cela qu'on parle ici), dès qu'il y a un OS, on est entre de la programmation embarquée et de la programmation mobile (d'après ce que j'ai appris).

Donc oui, je conseille d'allouer et de liberer la memoire au fur et a mesure des besoins.

On a jamais dit de ne pas libérer soit-même la mémoire, juste que si il y a une petite fuite de mémoire (ce qui peut arriver et que atexit() était censé nous éviter), ce n'est pas très "grave" (vu que l'OS est censé libérer la mémoire) et qu'en cas de plantage, atexit() ne servira à rien.
On a ensuite justifié le fait que l'OS devait libérer la mémoire par le fait qu'en cas de plantage, la mémoire doit aussi être libérée. Ainsi si le programme plante et que l'OS ne fait pas son boulot... ce n'est pas un bon OS.