probleme avec la commande goto en language C
- Créateur du sujet J£$µ$
- Date de début
J£$µ$ a dit:
Bonjour,
Ne JAMAIS utiliser goto en C, est je pense, le meilleur conseil que je puisse te donner.
Cordialement
J£$µ$ a dit:
Bonjour,
Tu utilise un appel a une fonction, des "if else", etc.
N'utilse jamais Goto et limite le "break" aux "switch-break".
Cordialement
molgow a dit:Et dans n'importe quel langage autre que le C, le conseil est aussi valable
Il n'est JAMAIS nécessaire d'utiliser un GOTO, on peut toujours faire autrement.
Pas tout à fait vrai, en Fortran II, III et même iV autant que je m'en souvienne, on était obligé de l'utiliser
Même chose sur le basic applesoft de l'apple II. Bon, ça nous rajeunit pas tout ça : en fait le goto est à l'informatique ce que la lampe à huile est à l'éclairage : ça fume, ça éclaire mal, ça peut foutre le feu, ceci dit, chacun ses goûts et ses risques.
PS. Depuis les débuts de l'ère de la programmation structurée, le GOTO est quasi- persona non grata, une des (très rares) exceptions étant de permettre de sortir d'un programme rapidement et proprement (enfin, ça faut s'en occuper quand même). Le GOTO existe d'ailleurs, même en Pascal. Mais, durant mes années de programmation Pascal, je n'en ai jamais, je dis bien jamais, utilisé l'ombre d'un seul (pas plus que dans la suite d'ailleurs, mais comme j'ai peu programmé en C). :zen:
alf_zorro a dit:
C'est là tout le problème : même avec la meilleure volonté du monde, on peut toujours faire des conneries, autant utiliser des constructions qui par nature t'en évitent certaines. :zen:
Pour répondre à Jesus, il te faut créer une étiquette
PYTHAGORE:
à l'endroit où tu veux sauter.
Comme dit plus haut, c'est une très mauvaise habitude d'utiliser un goto. Je ne connais que deux cas intéressant d'utilisation:
for(compteur1 = 0; compteur1 <= 100000; compteur1++)
{
for(compteur2 = 0; compteur2 <= 100000; compteur2++)
{
if( une condition )
goto finBoucle;
}
}
finBoucle:
Le goto est ici la meilleure solution (lisibilité, performances), autrement, il faut retester la condition dans la boucle de compteur1.
Autre cas: quand vous faîtes de la gestion d'erreur, vous sautez directement à la fin dès qu'une erreur apparaît.
Comme le conseille M. Kernighan, il faut par contre absolument éviter les goto pour sauter en arrière.
PYTHAGORE:
à l'endroit où tu veux sauter.
Comme dit plus haut, c'est une très mauvaise habitude d'utiliser un goto. Je ne connais que deux cas intéressant d'utilisation:
for(compteur1 = 0; compteur1 <= 100000; compteur1++)
{
for(compteur2 = 0; compteur2 <= 100000; compteur2++)
{
if( une condition )
goto finBoucle;
}
}
finBoucle:
Le goto est ici la meilleure solution (lisibilité, performances), autrement, il faut retester la condition dans la boucle de compteur1.
Autre cas: quand vous faîtes de la gestion d'erreur, vous sautez directement à la fin dès qu'une erreur apparaît.
Comme le conseille M. Kernighan, il faut par contre absolument éviter les goto pour sauter en arrière.
Bonsoir,
Je suis d'accord Feroce, mais on aurait put aussi bien écrire les boucles imbriquées dans une fonction et placer un "return" au bon endroit.
Je me permet une remarque générale:
- Continuez a utiliser des "goto"
- Ne commentez pas vos sources
- Donnez des noms abscons a vos fonctions et variables
Comme on vous l'apprends a l'ecole, où l'on voit le C le Lundi, le C++ le Mardi, et le Java le Mercredi.
Et vous passerez à coté d'une des grandes joie, la **programmation** et deviendrez Chef de Projet ou Commercial. Avant de vous demander quel est le but de tout cela.
Cordialement
Je suis d'accord Feroce, mais on aurait put aussi bien écrire les boucles imbriquées dans une fonction et placer un "return" au bon endroit.
Je me permet une remarque générale:
- Continuez a utiliser des "goto"
- Ne commentez pas vos sources
- Donnez des noms abscons a vos fonctions et variables
Comme on vous l'apprends a l'ecole, où l'on voit le C le Lundi, le C++ le Mardi, et le Java le Mercredi.
Et vous passerez à coté d'une des grandes joie, la **programmation** et deviendrez Chef de Projet ou Commercial. Avant de vous demander quel est le but de tout cela.
Cordialement
Je suis d'accord avec Didier, les goto rende le code illisible.
Même pour un tout petit code, il ne faut pas prendre de mauvaises habitudes.
Je n'utilise JAMAIS le goto en C.
En fait à l'école, on en a même jamais parlé.
Pour les commentaires et les noms de fonctions, il faut essayé le plus possible d'être consistant et explicite.
Même pour un tout petit code, il ne faut pas prendre de mauvaises habitudes.
Je n'utilise JAMAIS le goto en C.
En fait à l'école, on en a même jamais parlé.
Pour les commentaires et les noms de fonctions, il faut essayé le plus possible d'être consistant et explicite.
Céroce a dit:
Ce sont effectivement les cas "justifiables". Encore doit-on noter que les langages se sont dotés la plupart du temps, d'abord d'instructions de type "exit" qui gèrent ça propement ; ensuite de traitement d'exceptions qui peuvent être utiles aussi.
En ce qui concerne la lisiblité (quand on n'a pas d'"exit"), ça peut être effectivement plus clair. En ce qui concerne les performances, ce serait à vérifier : ne jamais oublier que les compilateurs savent optimiser et ils peuvent être parfois d'une efficacité redoutable (pas toujours
). Je me rappelle avoir fait, il y a bien longtemps des tests à ce niveau sur du fortran, c'était assez rigolo. Par exemple, on expliquait bien sûr qu'il valait mieux définir la valeur d'une variable qui n'avait plus à bouger avant une boucle plutôt que dedans. Mais en fait, au niveau du temps de calcul (et en fait du code compilé), c'était la même chose (faut dire que c'est pas très difficile à détecter). D'autres optimisations beaucoup plus tordues peuvent être effectuées par le compilo.Je ne suis pas d'accord avec vous, dans le sens où il existe souvent UNE solution plus adaptée que toutes les autres à un problème donné.
Si j'évalue que le goto est la meilleure solution à mon problème (encore une fois, c'est rarement le cas), alors je l'utilise. Je ne vais pas m'en priver par _principe_.
Si j'évalue que le goto est la meilleure solution à mon problème (encore une fois, c'est rarement le cas), alors je l'utilise. Je ne vais pas m'en priver par _principe_.
Céroce a dit:
Ce n'est pas un principe, c'est un conseil.
Cela fait pas mal de temps que j'écrit du C tous les jours, 18 ans en fait, et je n'ai jamais trouvé de cas où son utilisation s'imposait. A mon avis, si le goto devient la seule solution, c'est que la structure de ta fonction est mauvaise.
Cordialement
entièrement d'accord... d'ailleur heureusement qu'il y a ce genre de post pour me rappeler que ca existe le gotoDidier Guillion a dit:
(ok, j'exagère un peu...)ca me rappelle les débats trollistiques sans fin sur usenet il y a quelques siècles...
du genre "Isn't #defining TRUE to be 1 dangerous, since any nonzero value is considered "true'' in C? What if a built-in logical or relational operator "returns'' something other than 1?"
"Is it acceptable for one header file to #include another?"
ou encore ca: "Is the abbreviated pointer comparison "if(p)'' to test for non-null pointers valid? What if the internal representation for null pointers is nonzero?"
avec les flame-wars qui s'en suivaient
Didier Guillion a dit:
je sens que mon commentaire a été mal pris
heuh moi non plus je n'utilise jamais le goto, et même si j'ai 9 fois moins d'années d'expériences en C que toi, j'ai appris le C en lisant du code noyau, et force est de constater que ce goto est très présent les kernels!
et je suis tout à fait d'accord, il vaut mieux l'éviter, mais pour les gens qui ont commencé par l'assembleur, un goto ou un while,etc..., ça ne change pas grand chose, c'est "juste" une vue de l'esprit, enfin, à mon humble avis.
heuh, grosse parenthèse, en cherchant sur le web ton nom (des fois que tu aurais été un de mes profs à la fac
), je suis tombé sur sapiens, c'est le même toi qui l'a fait? parce que j'adorais ce jeu quand j'étais gamin!
alf_zorro a dit:je sens que mon commentaire a été mal pris
heuh moi non plus je n'utilise jamais le goto, et même si j'ai 9 fois moins d'années d'expériences en C que toi, j'ai appris le C en lisant du code noyau, et force est de constater que ce goto est très présent les kernels!
et je suis tout à fait d'accord, il vaut mieux l'éviter, mais pour les gens qui ont commencé par l'assembleur, un goto ou un while,etc..., ça ne change pas grand chose, c'est "juste" une vue de l'esprit, enfin, à mon humble avis.
heuh, grosse parenthèse, en cherchant sur le web ton nom (des fois que tu aurais été un de mes profs à la fac
Bonjour,
Cela veut peut etre dire que les Kernels ne sont pas tous bien écrit...
Oui, je suis l'auteur de Sapiens, écrit en 6809 sur les Thomsons, reecrit en Z80 pour Amstrad , puis 68000 et C pour la version Atari et enfin 8086 pour la version PC. Ouf !
A l'époque rien n'existait. Quand tu voulais programmer un jeu, tu commencait par t'écrire un assembleur en basic, puis tu reecrivait l'assembleur en assembleur pour que ca aille plus vite, et tu pouvait commencer ton jeu...
Cordialement
Didier Guillion a dit:
et bien merci pour les heures de jeu! et je comprends mieux pourquoi tu détestes les goto
j'ai trouvé un chtit exemple de goto dans OS X (dans posix_sem.c, gestion des sémaphores POSIX):
et pourtant la norme comprenant les sémapgores POSIX date de plus ou moins 94!
Sujets similaires
macOS Monterey
Problème de commande terminal command no found
