petit problème de liste chaînée

Version imprimable

salut à tous :D.
j'aimerais bien que vous m'aidai j'ai un problème dans la lecture des listes (simplement et doublement ) chaînées mais le grands souci c'est que je comprend le cours mais pas le code en c , par exemple se code source de l’insertion d'une liste simplement chaînée au début .
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 void insertion(Liste *liste, int nvNombre) { /* Création du nouvel élément */ Element *nouveau = malloc(sizeof(*nouveau)); if (liste == NULL || nouveau == NULL) { exit(EXIT_FAILURE); } nouveau->nombre = nvNombre; /* Insertion de l'élément au début de la liste */ nouveau->suivant = liste->premier; liste->premier = nouveau; }
aider mois'il vous plais :(

Citation:
Envoyé par fashi
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 void insertion(Liste *liste, int nvNombre) { /* Création du nouvel élément */ Element *nouveau = malloc(sizeof(*nouveau)); if (liste == NULL || nouveau == NULL) { exit(EXIT_FAILURE); } nouveau->nombre = nvNombre; /* Insertion de l'élément au début de la liste */ nouveau->suivant = liste->premier; liste->premier = nouveau; }
aider mois'il vous plais :(
Bonjour

Telle que présentée ta fonction est correcte. Sous réserve que lors de l'initialisation de ta liste au tout début, l'élément liste->premier ait été bien mis à NULL pour que ce NULL se propage sur le tout premier élément (premier élément qui devient alors le dernier de ta liste puisque les autres s'insèrent devant lui).
Donc le souci doit se situer ailleurs.

Ceci dit ce n'est pas parfait. Par exemple si "liste" est NULL, ben t'as fait une allocation pour rien ce qui provoque alors une fuite de mémoire. De plus on ne quitte jamais une fonction via exit(). C'est une solution de simplicité trop facile et trop fainéante. Si une fonction ne peut pas accomplir son travail, et que ce travail est important, alors la fonction doit remonter une valeur spéciale (ce que fait d'ailleurs malloc() ou fopen() qui renvoient "NULL" en cas d'échec) et c'est alors au parent de gérer (parent qui, lui aussi, devra réagir autrement que par un exit()).

Ici un exemple fonctionnel et complet de liste chainée.

09/09/2018, 09h53
Christophe

https://chgi.developpez.com/liste/
09/09/2018, 14h05
sambia39
Bonjour,
 Si vous utilisez le langage de programmation C sans comprendre le sens ou l’emploi des instructions, c’est que vous n’avez tout simplement pas compris le cours en question (et probablement celui en algorithme/algorithmique en passant).

Pour la compréhension, on parlera de la définition de votre fonction qui porte le nom « insertion » et qui a pour type void, elle admet deux arguments/paramétres sous forme type argument1, type argument2. Le type de votre fonction est void, ce qui veut dire qu’elle ne retourne rien même pas une valeur. Ainsi donc en informatique, l’appellation d'une tels fonctions est « procédure », car elle ne retourne rien (contrairement à une fonction), mais doit effectuer une tâche bien précise. Au final, la première ligne est non pas une définition de fonction, mais de procédure qui admet des paramètres dits également arguments.
Votre procédure en détail est définie ainsi :
1. ligne 1: Définition de la procédure qui porte le nom de insertion avec comme paramètre Liste *liste , int nv nombre
  - Liste *liste , int nvnombre caractérise le type et le nom des paramètres dont :
    
    Liste *liste est un pointeur, plus précisément une variable de type adresse qui contient l’adresse associée au type en question à savoir "Liste". Liste est donc le type de l’objet sur lequel on pointe (fait référence).
    liste est la variable qui contient l’adresse où se trouve l’objet en mémoire; nvnombre est une variable de type entier qui n’est pas un pointeur, mais qui admettra une valeur.
    La particularité de cette variable est qu'elle contiendra une copie de la valeur originale et donc toute modification sur cette variable n’affectera pas la variable d’origine ; contrairement à un pointeur qui permet de modifier la valeur qui se trouve à l’adresse en question. Cela veut dire que si vous modifiez la valeur d’une variable à travers sa variable pointeur, la valeur de la variable se voit également modifier puisque vous connaissez son adresse (emplacement mémoire).
2. Ligne 4, 5 : ligne 4 : déclaration une variable de type pointeur vers une structure du type Elements qui contiendra l’adresse mémoire où se trouve l’objet du type Elements. À la ligne 5, on utilise une structure conditionnelle communément appelée « si en french » et qui évalue l’expression (liste == NULL || nouveau == NULL) et donc savoir si réellement « liste » vaut nul ou si « nouveau vaut réellement nul ». L’emploi du OU (||) en langage C permet donc de vérifier qu’une des conditions est réalisée et comme l’a souligné @Sve@r sur une des conditions, vous aurez une fuite mémoire.
3. Ligne 7 : votre programme s’arrête et rend la main au système d’exploitation en l’informant que le programme s’est interrompu de manière infructueuse, ce qui est correct car cela veut dire que la procédure n’a su réaliser sa tâche et s’arrête immédiatement en informant du problème. À la ligne 9 à 13, on considère que tout se passe bien et que l’on peut assigner la valeur dans le nouvel élément et ensuite procéder au chaînage.
Citation:

Envoyé par Sve@r

De plus on ne quitte jamais une fonction via exit(). C'est une solution de simplicité trop facile et trop fainéante. Si une fonction ne peut pas accomplir son travail, et que ce travail est important, alors la fonction doit remonter une valeur spéciale (ce que fait d'ailleurs malloc() ou fopen() qui renvoient "NULL" en cas d'échec) et c'est alors au parent de gérer (parent qui, lui aussi, devra réagir autrement que par un exit()).

Sve@r: ça n’a pas vraiment d’importance puisque exit() est strictement équivalent à un return EXIT_FAILURE, avec la particularité d’être invoqué n’importe où dans le programme même dans une procédure. Là où cela ne devient non portable/propre et qui n’est pas conseillé, c’est l’emploi de la fonction exit() sous cette forme exit(1)/exit(0), car sur d’autres implémentations (OS) cela indique que le programme a terminé avec succès hors, ce n’est pas le cas. Le mieux serait alors d’utiliser EXIT_FAILURE, cela aura pour avantage de s’adapter automatiquement et donc une meilleure portabilité. Pour le cas actuels l’instruction en question fais très bien l’affaire. Mais à l'avenir, il faudra effectivement faire remonter l'information d'échec et que le programme puisse prendre les mesures nécessaires.

à bientôt.
09/09/2018, 20h45
Sve@r

Citation:

Envoyé par sambia39

puisque exit() est strictement équivalent à un return EXIT_FAILURE,

Certainement pas. Déjà d'un point de vue logique, avoir deux instructions différentes strictement équivalentes est totalement idiot et contre-productif.
Et en réalité exit() fait sortir du programme tandis que return fait sortir de la fonction. Ce n'est donc pas équivalent du tout (en dehors du main()).

Citation:

Envoyé par sambia39

Pour le cas actuels l’instruction en question fais très bien l’affaire.

Ben non.

Citation:

Envoyé par sambia39

Au final, la première ligne est non pas une définition de fonction, mais de procédure qui admet des paramètres dits également arguments.

En Pascal on fait peut-être la différence entre "fonction" et "procédure" mais pas en C.
09/09/2018, 23h32
fashi

merci beaucoup de votre aide chers amis :D

Je crois rêver là. void insertion(Liste *liste, int nvNombre) renvoie-t-il quelque chose ?.Absolument rien, donc on ne peut que soit interrompre le programme (effectuer une terminaison anormale du processus) avec:
- abort() sous condition que le programme ait atteint ou exécuté une instruction illégale (et ce n’est pas le cas) ce qui déclenchera l’émission d’un signal par défaut qui procédera à l’arrêt du processus en créant un core dump.
- ou de manière portable et propre avec exit() pour terminer le processus (Pour les barbares ça sera _Exit()) ou dans le cas d'une fonction qui renvoie la valeur signifiant l'erreur à faire remonter.

Citation:

Envoyé par Sve@r

Certainement pas. Déjà d'un point de vue logique, avoir deux instructions différentes strictement équivalentes est totalement idiot et contre-productif.
Et en réalité exit() fait sortir du programme tandis que return fait sortir de la fonction. Ce n'est donc pas équivalent du tout (en dehors du main()).

EXIT_SUCCESS et EXIT_FAILURE; sont des constantes symboliques pour signifier respectivement une terminaison en succès ou en échec du processus. Et d'ailleurs, que l’on fasse return EXIT_SUCCESSou return EXIT_FAILURE; dans un programme, le programme (processus) s’arrête en invoquant exit(EXIT_FAILURE)/exit(EXIT_SUCCESS). Pour être encore beaucoup plus précis, il invoque exit_group(statut) dont le statut est l'agument passé à la fonction exit() ou le fameux return EXIT_SUCCESS. Un tour sur le man "exit_group" fournira également d'avantage d'informations et voici la preuve de ce que j'avance.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 #include <stdio.h> #include <stdlib.h> void foo(void){ (void)puts("fin de programme"); } void sortie_forcer( void ){ exit(EXIT_FAILURE); } int main( void ){ atexit(foo); /*sortie_forcer();*/ (void)puts("programme va s'arreter"); return EXIT_SUCCESS; }
Code:

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 31 32 33 34 35 36 37 jager@Forensic:~/debug$ uname -a Linux Forensic 4.15.0-23-generic #25-Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux jager@Forensic:~/debug$ gcc *.c -Wall -Werror -g -o Deb && strace ./Deb execve("./Deb", ["./Deb"], 0x7fff0f4ea3c0 /* 21 vars */) = 0 brk(NULL) = 0x562114625000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=36640, ...}) = 0 mmap(NULL, 36640, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fa7cdd7d000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\34\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=2030544, ...}) = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa7cdd7b000 mmap(NULL, 4131552, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa7cd76e000 mprotect(0x7fa7cd955000, 2097152, PROT_NONE) = 0 mmap(0x7fa7cdb55000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e7000) = 0x7fa7cdb55000 mmap(0x7fa7cdb5b000, 15072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa7cdb5b000 close(3) = 0 arch_prctl(ARCH_SET_FS, 0x7fa7cdd7c4c0) = 0 mprotect(0x7fa7cdb55000, 16384, PROT_READ) = 0 mprotect(0x562113766000, 4096, PROT_READ) = 0 mprotect(0x7fa7cdd86000, 4096, PROT_READ) = 0 munmap(0x7fa7cdd7d000, 36640) = 0 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 brk(NULL) = 0x562114625000 brk(0x562114646000) = 0x562114646000 write(1, "programme va s'arreter\n", 23programme va s'arreter ) = 23 write(1, "fin de programme\n", 17fin de programme ) = 17 exit_group(0) = ? +++ exited with 0 +++ jager@Forensic:~/debug$
Et maintenant le même exemple sans return EXIT_FAILURE cela donne le même résultat:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 #include <stdio.h> #include <stdlib.h> void foo(void){ (void)puts("fin de programme"); } void sortie_forcer( void ){ exit(EXIT_FAILURE); } int main( void ){ atexit(foo); sortie_forcer(); (void)puts("programme va s'arreter"); return EXIT_SUCCESS; }
Code:

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 31 32 33 jager@Forensic:~/debug$ gcc *.c -Wall -Werror -g -o Deb && strace ./Deb execve("./Deb", ["./Deb"], 0x7ffcc9a6f030 /* 21 vars */) = 0 brk(NULL) = 0x563b65e8f000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=36640, ...}) = 0 mmap(NULL, 36640, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fdb93a69000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\34\2\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=2030544, ...}) = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fdb93a67000 mmap(NULL, 4131552, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fdb9345a000 mprotect(0x7fdb93641000, 2097152, PROT_NONE) = 0 mmap(0x7fdb93841000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e7000) = 0x7fdb93841000 mmap(0x7fdb93847000, 15072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fdb93847000 close(3) = 0 arch_prctl(ARCH_SET_FS, 0x7fdb93a684c0) = 0 mprotect(0x7fdb93841000, 16384, PROT_READ) = 0 mprotect(0x563b64b50000, 4096, PROT_READ) = 0 mprotect(0x7fdb93a72000, 4096, PROT_READ) = 0 munmap(0x7fdb93a69000, 36640) = 0 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 brk(NULL) = 0x563b65e8f000 brk(0x563b65eb0000) = 0x563b65eb0000 write(1, "fin de programme\n", 17fin de programme ) = 17 exit_group(1) = ? +++ exited with 1 +++ jager@Forensic:~/debug$
montrez-moi en quoi les deux instructions ne sont pas équivalentes ?

Parlant du point de vue logique dans le contexte actuel. On a une fonction qui ne renvoie aucune valeur (procédure), dont celle-ci n'a pas rencontré ou effectué une opération illégale, comme par exemple l’accès à un pointeur non initialisé, on peut donc termine le processus avec abort et un fichier core est créé. Soit on invoque exit() pour interrompre ou quitter proprement de mainière portable.

De toute façon, peu importe lorsque votre processus se termine en revenant du main avec un return EXIT_SUCCESS/ return EXIT_FAILURE; le processus invoquera exit() et la bibliothèque C prend le relais et effectue les opérations suivantes
 -Appels de toutes les fonctions qui ont été enregistrées à l’aide des routines atexit() et on_exit() 
-Fermeture de tous les flux d’entrée-sortie et suppression de fichiers crées par la fonction tmpfile()
 -Puis invocation de la fonction _extit().   

Citation:

Envoyé par Sve@r

En Pascal on fait peut-être la différence entre "fonction" et "procédure" mais pas en C.

J’ai parlé en terme d’informatique et algorithme, et non de la façon dont on perçoit une fonction au niveau du langage C. Et donc, du point de vue informatique (en général) et logique ou algorithme, les procédures sont des fonctions qui ne retournent rien et en C, c'est le cas même si, on ne fait pas cette distinction. 

10/09/2018, 09h34
Sve@r

Citation:

Envoyé par sambia39

Je crois rêver là.

Tu vas te calmer immédiatement avec les sarcasmes parce que sinon tu vas voir que je sais moi aussi me débrouiller avec !!!

Citation:

Envoyé par sambia39

void insertion(Liste *liste, int nvNombre) renvoie-t-il quelque chose ?.Absolument rien, donc on ne peut que soit interrompre le programme (effectuer une terminaison anormale du processus) avec:
- abort() sous condition que le programme ait atteint ou exécuté une instruction illégale (et ce n’est pas le cas) ce qui déclenchera l’émission d’un signal par défaut qui procédera à l’arrêt du processus en créant un core dump.
- ou de manière portable et propre avec exit() pour terminer le processus (Pour les barbares ça sera _Exit()) ou dans le cas d'une fonction qui renvoie la valeur signifiant l'erreur à faire remonter.

Ben non. Donc on a aussi le droit de mettre un return même dans une fonction "void".

Par ailleurs si tu lis attentivement ce que j'avais écrit...

Citation:

Envoyé par Sve@r

Si une fonction ne peut pas accomplir son travail, et que ce travail est important, alors la fonction doit remonter une valeur spéciale.

Tu comprendras (j'espère :roll:) que d'une part je ne parlais absolument pas d'interrompre le programme mais de "remonter" une valeur à la fonction parente (citée quelques mots plus loins) et d'autre part cela sous-entend bien évidemment que la fonction change et ne soit plus "void". Je ne l'avais pas écrit tellement cela me paraissait évident pour tous sauf pour toi apparemment :roll:

Citation:

Envoyé par sambia39

Citation:

Envoyé par sambia39

ça n’a pas vraiment d’importance puisque exit() est strictement équivalent à un return EXIT_FAILURE,

montrez-moi en quoi les deux instructions ne sont pas équivalentes ?

Déjà ton exemple consiste à appeler ou pas une sous-fonction (je nomme "sous-fonction" les fonctions autre que "main") qui contient un exit() donc en résumé à activer ou pas un exit() ; ce qui n'illustre absolument pas une comparaison entre exit() et return (objet de ton premier discours). Donc remplace, dans ta fonction "sortie_forcer", le exit() par un return et tu la verras la différence. Et par pitié, arrête tes casts totalement bidons ((void)puts(...)) qui montrent que tu ne connais absolument rien au C et à ses casts implicites qui, eux, sont bien plus performants (car eux ne masquent pas les warnings indiquant un problème possible).

Citation:

Envoyé par sambia39

J’ai parlé en terme d’informatique et algorithme, et non de la façon dont on perçoit une fonction au niveau du langage C. Et donc, du point de vue informatique (en général) et logique ou algorithme, les procédures sont des fonctions qui ne retournent rien et en C, c'est le cas même si, on ne fait pas cette distinction. 

Oui mais tout le monde s'en fout. Tout comme M. Jourdain faisait de la prose sans le savoir (et pourquoi ne le savait-il pas ? Parce que cela ne lui apportait absolument rien de le savoir) les codeurs en C n'ont que faire de distinguer fonctions et procédures. Que ce soit le débutant qui tente péniblement de faire marcher sa liste chainée jusqu'au professionnel qui code des drivers. J'irai même jusqu'à dire que Kernighan et Ritchie s'en balançaient totalement quand ils ont posé les bases du langage. Pour résumer, ici tout le monde s'en branle de ta science pompeuse et de tes distinctions entre "fonction" et "procédure" qui n'apportent absolument rien à la résolution du problème initialement présenté par le PO (ce qui reste quand-même le but premier de ce forum).

PS: je n'aime absolument pas ta citation "celui qui peut agit, celui qui ne peut pas enseigne". Déjà c'est insultant envers tous les professeurs et enseignants du monde. De plus, enseigner c'est transmettre le savoir qui permet à l'humanité d'évoluer et donc fallait vraiment être un petit révolutionnaire torturé et aigri pour ne pas s'en rendre compte et sortir une telle aberration.
11/09/2018, 11h11
sambia39

1) J’ai parlé d’interrompre le programme parce que la fonction en question du PO met un terme à l’exécution du programme en sortant avec exit(EXIT_SUCCESS) et que l’appel de exit(EXIT_SUCCESS) est correct puisque l’on interrompt le programme suite à une erreur d’allocation comme le PO l'écrit.

Citation:

Envoyé par Sve@r

Ben non. Donc on a aussi le droit de mettre un return même dans une fonction "void".
Par ailleurs si tu lis attentivement ce que j'avais écrit...
Tu comprendras (j'espère :roll:) que d'une part je ne parlais absolument pas d'interrompre le programme mais de "remonter" une valeur à la fonction parente (citée quelques mots plus loins) et d'autre part cela sous-entend bien évidemment que la fonction change et ne soit plus "void". Je ne l'avais pas écrit tellement cela me paraissait évident pour tous sauf pour toi apparemment :roll:

2)Je n'ai pas spécifié le contraire de ce que tu as écris, j'ai précisé que ça n’a pas vraiment d’importance puisque exit(EXIT_SUCCESS) a le même effet que return EXIT_SUCCESS et tout comme toi, je n’ai pas précisé que c’était dans le main tellement que ça paraissait évident surtout que je m’adressais à toi et non au PO.  

Citation:

Envoyé par sambia39

Pour le cas actuels l’instruction en question fais très bien l’affaire. Mais à l'avenir, il faudra effectivement faire remonter l'information d'échec et que le programme puisse prendre les mesures nécessaires.
à bientôt.

3) return dans une fonction void ne retourne rien et si on a le droit de mettre un return; dans une fonction qui ne renvoie rien, c’est pour une sortie immédiate sous une condition / que l’on ne veut pas poursuivre l’exécution.   

Citation:

Envoyé par Sve@r

Déjà ton exemple consiste à appeler ou pas une sous-fonction (je nomme "sous-fonction" les fonctions autre que "main") qui contient un exit() donc en résumé à activer ou pas un exit() ; ce qui n'illustre absolument pas une comparaison entre exit() et return (objet de ton premier discours). Donc remplace, dans ta fonction "sortie_forcer", le exit() par un return et tu la verras la différence. Et par pitié, arrête tes casts totalement bidons ((void)puts(...)) qui montrent que tu ne connais absolument rien au C et à ses casts implicites qui, eux, sont bien plus performants (car eux ne masquent pas les warnings indiquant un problème possible).

4) J’ai spécifié avec un exemple ce qui se passait si on avait exit(EXIT_SUCCESS) et return EXIT_SUCCESS. Et je pense avoir bien écrit return EXIT_SUCCESS dans mes précédents messages dans le main et non return, tu as dû mal lire ou comprendre peut-être. Sur le cast faudrait-il que je refasse ton éducation en C ?. look 6.8.3 Expression and null statements dans la norme . On a parfaitement le droit d' ignorer la valeur de retour d'une fonction qui est rarement utilisé et ce n’est pas pour faire taire les warning.

  5) Enseigner, c’est susciter l'apprentissage, ce n’est pas juste transmettre une connaissance,. J’aurais aimé être d’accord avec toi là-dessus, mais on aurait tous deux tort. Que ma citation t’agaces ou que ma science te déranges, que tu parles de ce que les autres pensent, tu n’es pas non plus bien placé pour donner des leçons ou parler à leur place pour rester que poli.
11/09/2018, 12h38
Sve@r

Citation:

Envoyé par sambia39

Citation:

Envoyé par sambia39

Citation:

Envoyé par Sve@r

De plus on ne quitte jamais une fonction via exit(). C'est une solution de simplicité trop facile et trop fainéante. Si une fonction ne peut pas accomplir son travail, et que ce travail est important, alors la fonction doit remonter une valeur spéciale (ce que fait d'ailleurs malloc() ou fopen() qui renvoient "NULL" en cas d'échec) et c'est alors au parent de gérer (parent qui, lui aussi, devra réagir autrement que par un exit()).

Sve@r: ça n’a pas vraiment d’importance puisque exit() est strictement équivalent à un return EXIT_FAILURE, avec la particularité d’être invoqué n’importe où dans le programme même dans une procédure. Là où cela ne devient non portable/propre et qui n’est pas conseillé, c’est l’emploi de la fonction exit() sous cette forme exit(1)/exit(0), car sur d’autres implémentations (OS) cela indique que le programme a terminé avec succès hors, ce n’est pas le cas. Le mieux serait alors d’utiliser EXIT_FAILURE, cela aura pour avantage de s’adapter automatiquement et donc une meilleure portabilité. Pour le cas actuels l’instruction en question fais très bien l’affaire. Mais à l'avenir, il faudra effectivement faire remonter l'information d'échec et que le programme puisse prendre les mesures nécessaires.

1) J’ai parlé d’interrompre le programme parce que la fonction en question du PO met un terme à l’exécution du programme en sortant avec exit(EXIT_SUCCESS) et que l’appel de exit(EXIT_SUCCESS) est correct puisque l’on interrompt le programme suite à une erreur d’allocation comme le PO l'écrit.

Non, tu m'as cité quand j'ai écrit "ne pas sortir d'une fonction via exit" donc c'était clairement une réponse à ma phrase qui dit de ne pas sortir du programme et non une réponse au PO.

Citation:

Envoyé par sambia39

Citation:

Envoyé par Sve@r

Et en réalité exit() fait sortir du programme tandis que return fait sortir de la fonction. Ce n'est donc pas équivalent du tout (en dehors du main()).

2)Je n'ai pas spécifié le contraire de ce que tu as écris, j'ai précisé que ça n’a pas vraiment d’importance puisque exit(EXIT_SUCCESS) a le même effet que return EXIT_SUCCESS et tout comme toi, je n’ai pas précisé que c’était dans le main tellement que ça paraissait évident surtout que je m’adressais à toi et non au PO.  

Ben justement j'avais pourtant clairement écrit "en dehors du main" donc là c'était bien précisé (et par conséquent encore plus évident) que c'était hors du main !!!

Citation:

Envoyé par sambia39

14) J’ai spécifié avec un exemple ce qui se passait si on avait exit(EXIT_SUCCESS) et return EXIT_SUCCESS. Et je pense avoir bien écrit return EXIT_SUCCESS dans mes précédents messages dans le main

Ben voilà. Encore une fois tu es HS puisque le PO a montré une fonction qui n'est pas main() et que de nouveau j'avais bien spécifié "hors main()" !!!

Citation:

Envoyé par sambia39

On a parfaitement le droit d' ignorer la valeur de retour d'une fonction qui est rarement utilisé

Oui comme on a parfaitement le droit de ne pas l'ignorer tout en laissant le cast implicite l'ignorer à ta place. Economies de temps, économies de brain, économie dans l'évolution, économies de tout quoi. Je sais pas moi. Il ne te vient pas à l'idée de mettre tes variables en "register" parce que tu sais que le compilo le fera mieux que toi. Alors si tu lui fais confiance sur ce point, pourquoi tu ne lui fais pas confiance sur cet autre ? Et puis c'est quand-même pas agréable à relire quoi.

Citation:

Envoyé par sambia39

et ce n’est pas pour faire taire les warning.

Il s'agit là d'un effet de bord involontaire. Tu ne fais pas ces casts pour explicitement ignorer les warnings mais s'il doit y en avoir ben ils n'apparaissent plus.

Citation:

Envoyé par sambia39

Enseigner, c’est susciter l'apprentissage, ce n’est pas juste transmettre une connaissance

Oui si tu veux. Tant que ce n'est pas issu d'une négation de qualité comme "ne pas pouvoir" tout me va. Alors si tu crois aux qualités de l'enseignement, pourquoi tu encenses tant cette citation qui dit clairement le contraire ???

Citation:

Envoyé par sambia39

ou que ma science te déranges

Ce n'est pas tant ta science que son étalage à tout bout de champ et y compris (comme ici) totalement hors contexte. Et encore là ça aurait passé si t'étais pas venu en plus me casser les noix à vouloir absolument avoir raison en disant que "return" est identique à "exit" alors qu'il est clair que (hors main) ce n'est pas le cas.