Version imprimable
Disons, que dans la theorie, le goto peut-etre utilise mais il est rare qu'il soit necessaire ou qu'il soit meme souhaitable. Son utilisation rend l'algorithme difficilement comprehensible par un oeil externe (pareil que pour le break ou le continue) et cela donne souvent du code spaghetti (qui va dans tous les sens)
Je le deconseille...
Si je ne me trompe pas, un mathématicien a démontré qu'on pouvait en toute occasion se passer du goto. Ceci dit, pour se sortir d'un imbrication de boucle ça peut-être utile, mais c'est en général (99,99 % des cas) le signe d'une (très) mauvaise analyse/conception de l'algorithme.
Disons qu'il faut l'utiliser avec modération.
Dans les boucles, il peut être utilisé à la place du break. Personellement je trouve que :
est plus parlant que :Code:
2
3
Code:
2
3
Dans ce cas à la place du "for" autant faire un "while" est on évite encore ces break ou goto assez moche :roll:
Rémiz :Personnellement, je n'aime pas. Pas tellement à cause du goto de ce code mais à cause de la présence d'un label FinRecherche , car on ne sait pas sans TOUT lire à partir de quel(s) endroit(s) du code on peut arriver là.Code:
2
3
fearyourself :Oui, mais au moins, avec break ou continue, on sait dans quelle direction du code se trouve la suite. Et le code est du type spaghetti mais peigné :wink:Citation:
Son utilisation rend l'algorithme difficilement comprehensible par un oeil externe (pareil que pour le break ou le continue)
Moi perso, en plus de deux ans de C, jamais utilisé de goto ou de jmp :lol:
Les standards de l'industrie imposent comme règle de ne jamais
utiliser de goto !
Se référer aux règles MISRA par exemple...
Après, faut voir si il faut rester dans l'amateurisme...
Je m'en suis servi à quelque reprise lorsque je dévellopais autour du noyau linux, en mode kernel par exemple. Par contre pour un programme utilisateur je ne vois pas pourquoi utiliser un goto.
Je suis certainement trop limité pour comprendre.
Pour ces codes, je préfère écrire de la façon suivante qui est plus lisible, plus parlant et plus concise.Citation:
Envoyé par Rémiz
En fait en regardant bien les deux codes, on voit bien qu'il ne s'agit pas de la même conception.Code:for(x=0; x<100 && val != tab[x]; x++);
Dans le code de rémiz, on dit
Pour chaque valeur de x incrémentée de 1, tant que x est strictement inférieure à 100, on teste si val est égal à tab[x]. Si ce test est valide on saute à un endroit appelé FinRecherche (avec goto) ainsi la boucle est stopée ou on sort de la boucle for (avec break;).
Dans mon code, on dit
Pour chaque valeur de x incrémentée de 1, tant que la valeur de x est strictement inférieure à 100 ET que val est différent de tab[x], on continue la boucle. Si l'une des deux conditions n'est pas respectée, la boucle est stoppée.
Il n'y a plus d'instruction pour dire que faire lorsque une condition est vérifiée comme c'est le cas dans le code de Rémiz.
Sinon personnellement, on m'a fortement déconseillé le goto car ça va devenir illisible au fur et à mesure du développement des logiciels. Le break et continue est à utiliser avec modération.
Néamoins J'utilise break uniquement pour le switch.
Franchement, je vais répéter ce qui a été dit dans ce topic, le goto casse la logique d'un programme, car quand on lit un programme et dés qu'on aperçoit un goto, il faudra chercher l'endroit pour continuer la logique de lecture ensuite revenir au point de goto pour voir si ça continue juste après la ligne ou il y a goto
C'est casse tête chinois pour la lecture.
Tandis que sans goto, on s'y prend le plaisir de lire du début jusqu'a la fin du programme et comprendre le programme
slt,
En ce qui concerne le goto, une ancienne légende dit qu'il est trop attaché à l'assembleur. Il fait peur à certains, c'est un peu une chasse au sorcière. Qu'importe, il faut savoir ce que tu veux, si ton programme est à usage perso, non probleme, sinon commente. Mais il ne faut pas barnir certaines formes du langage sous prétexte que dans les temps anciens, bien des origines de bug venait d'un goto mal controlé...
M'enfin n'oublies pas Java bien et C tant mieux
8)
J'apporte mon grain de sel, y'a pas de raison :)
A mon avis le principal reproche qu'on peut faire au goto (et à raison), c'est de casser l'aspect structuré du code, et surtout permettre des sauts en arrière, ce qui crée un flux programmatique qui se croise, le fameux "spaghetti code". Mais alors que dire des break, des continue, des return lorsqu'ils ne sont pas en fin de fonction ? Que dire même des switch ?
L'usage du goto se justifie dans deux cas bien précis :
:arrow: Permier cas, traitement d'erreur. Exemple :
Evidement on a un gros problème de code redondant, difficile à changer. On peut avantageusement le remplacer par la chose suivante :Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Certains pourront dire qu'on peut utiliser une fonction dans ce cas, mais celà peut ajouter une complexité inutile s'il y a beaucoup de termes à traiter et de plus on doit également modifier les paramètres de la fonction si on doit modifier le code de nettoyage.Code:
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
:arrow: Deuxième cas, pouvoir sortir rapidement d'une construction très complexe et remonter une erreur. Exemple :
Imaginez le code précédent avec 10 ou 15 niveaux d'imbrications et autant de remontées d'erreur possibles (on trouve ce genre de code dans le noyau linux en particulier). Je défie quiconque d'arriver à écrire quelquechose de lisible en utilisant uniquement des flags et des tests :) Le goto permet d'obtenir un code plus simple et plus lisible et semble donc ici le meilleur choix.Code:
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
Je justifie ma position en disant la chose suivante : si une technique de programmation rend à la fois le code plus clair et plus efficace, alors c'est elle qu'on doit choisir. Baser sa décision sur un dogmatisme quasi pavlovien ("le goto c'est mal") ne mène nulle part.
Je voudrais juste dire mon avis personnel:
certes le goto en général c'est mal et moi même je l'utilise très rarement et je le déconseille
MAIS
il est des cas très particulier où il me semble qu'il peut être utilisé sans risque et surtout il est des cas où ne pas l'utiliser peut rendre le code encore pire . Je ne ferais que citer le cas des imbrications multiples à condition que les boucles ne soient pas trop grandes(dans ce cas mieux vaut une fonction et un test) .
Je citerais aussi un cas très particulier qui m'est déjà arrivé:
Là c'est vraiment particulier mais dans certaines circonstances mieux vaut ne pas faire autrement à mon avisCode:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Dans cet exemple particulier, l'interet du goto est, si j'ai bien compris, d'executer dans le if() le meme code que dans un des case. Personellement, j'aurais plutot ecrit une fonction effectuant ce traitement et appele la fonction dans le if et dans le case.Citation:
Envoyé par amaury pouly
La portée des break et des continue est définie (bloc de structure de code). Avec un goto, c'est plus flou et on peut sortir brutalement d'une structure de code. Quand aux return multiples, je les combat aussi ardemment que les goto sauvages.Citation:
Envoyé par vic
Ok.Citation:
L'usage du goto se justifie dans deux cas bien précis :
:arrow: Permier cas, traitement d'erreur. Exemple :
Eventuellement, mais une variable 'err' bien gérée (0 = OK, non 0 = ERR) est très simple à intégrer dans les conditions des structures de code.Citation:
:arrow: Deuxième cas, pouvoir sortir rapidement d'une construction très complexe et remonter une erreur.
Je pense que tout le monde est d'accord pour dire 'le goto injustifié c'est mal tant qu'il existe une alternative simple et viable'. Ce discours s'adresse surtout aux débutants, afin de les inciter à utiliser les structures de codes qui couvrent 100% des cas. Ensuite, si on veut simplifier certains traitement 'exceptionnels', peut être. Mais il est certain que l'on peut toujours s'en passer.
Je ne l'ai pas fait car cette fonction est appelée trop souvent et puis que le traitement n'est pas très long(3-4 lignes) . Certes on aurait pû inliner mais pour moi çà n'en valait pas la peine .Citation:
Dans cet exemple particulier, l'interet du goto est, si j'ai bien compris, d'executer dans le if() le meme code que dans un des case. Personellement, j'aurais plutot ecrit une fonction effectuant ce traitement et appele la fonction dans le if et dans le case.
D'ailleurs dans cette structure il y avait d'autres cas qui rammenaient au cas.
Néanmoins c'est exceptionnel comme utilisation .
les gotos permettent de casser la structure logicielle. Typiquement, on peut faire des trucs comme ceci
Ici c'est facile, on a généré au beau bug facilement visible, mais parfois l'algorithme est plus complexe, et on ne voit pas ce type d'erreur.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Structurer correctement son logiciel permet de le rendre plus robuste, et plus facile à maintenir.
Si des normes d'écritures en langage C on dit qu'il ne fallait surtout pas l'utiliser, ce n'est pas pour rien.
A+
Personnelement je n'ia utilisé les goto que dans un domaine :
La programmation noyau Linux. Au début j'étais réticent à utiliser le Goto, mais au final, s'il est correctement utiliser il peut aider à la lisibilité du code.
J'utilisais donc le goto toujours en descendant pour la gestion des erreurs
par exemple
il est clair qu'il est toujours possible de faire sans, mais si on cadre bien son emploi, on peut alleger le code sans perdre en lisibilité et même en gagner un peu avec justement l'allegement du code.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
Je cite "Méthodologie de la programmation en C" de Jean Pierre Braquelaire , une référence dans le domaine de la prog !!! Mon mentor !! Un ancien prof de la fac il y a longtemps...
"
Le branchement est à utiliser avec la plus grande prudence. Cependant, il est parfois utile pour simuler des échappements non implémentés en C (essentiellement la sortie de plusieurs boucles imbriquées).
On ne doit l'utiliser seulement si les intrusctions break et continue sont insuffisantes. Par exemple, on ne peut, avec l'instruction break, sortir d'une boucle qui se trouve dans un aiguillage imbriqué dans la boucle. Dans ce cas, Break permet seulement de sortir de l'aiguillage.
La sortie de plusieurs boucles imbriquées est également un cas que l'on ne peut gérer avec un échappement. C'est le cas de l'exemple suivant, présentant le parcours d'une liste de listes avec arrêt sur le premier élément vérifiant une condition donnée :
On peut éviter ici l'utilisation du branchement en plaçant l'instruction dansCode:
2
3
4
5
6for (jour = 0; jour < 7; jour++) for (heure = 1; heure < 24; heure++) if (semaine[jour][heure]<semaine[jour][heure-1]) goto baisse; baisse:
une fonction, dont on sort au moyen d'un return :
Cependant, la gestion des paramètres par référence alourdit l'écriture et entraîne une duplication de code. Il est plus préférable d'écrire :Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Une autre utilisation classique du saut est la gestion d'erreurs, avec interruption du traitement (goto erreur) ou reprise (goto début). Tous cesCode:
2
3
4
5
6
7
8
9
10
11
12
13
exemples d'utilisation du branchement sont construits sur le même modèle: la sortie de plusieurs blocs imbriqués. Il est par contre préférable d'éviter d'utiliser un goto pour se déplacer dans un bloc ou pour rentrer dans un bloc de profondeur inférieure.
cela devrait clore un éternel débat qui n'a plus lieu d'être !!!
Salut, :D
Moi non plus j'aime pas les goto... il fut un temps où je les virais... Pourtant y'a pas que lui qui n'est pas structuré :
Mais dans un switch() case: break...
le break est un goto comme le continue dans un while() ou for(;;)
Souvent en virant un goto (mis par qq d'autre :wink: ), j'ai rendu le code moins joli (question de goût) mais je préfère...
v'la question de goût et d'expérience...
Je trouve tout de même une instruction switch beaucoup plus structurée qu'un goto. Contrairement au goto, je ne trouve pas qu'elle nuit à la lisibilité du code. Perso, je n'ai jamais utilisé la possibilité offerte par goto.Citation:
Moi non plus j'aime pas les goto... il fut un temps où je les virais... Pourtant y'a pas que lui qui n'est pas structuré :
Mais dans un switch() case: break...
Meilleures salutations
Thierry
Idem, je n'ai plus utilise un seul goto depuis le temps ou je programmais en Basic sur ma calculatrice sur les bancs du lycee... (aaah les cours de physique).Citation:
Envoyé par mujigka
Et je m'en porte tres bien.
:D OK pour le Goto, ce n’est pas beau…
8O Mais quand on parle de structure (voir réponse de Vic sur les break, continue, return…) je suis entièrement d’accord… et donc ce n’est pas la seule réponse pour ne pas utiliser le Goto.
:P Le seul langage qui respecte le flux de programmation… c’est le Lisp et ces dérivés… Pratiquez-le un peu (et même beaucoup) et vous connaîtrais les contraintes d’un respect des flux…
Un code C bien structuré qui n'utilise pas de goto et qui n'abuse pas de la compilation conditionnelle respecte à mon sens relativement bien le flux de programmation. Qu'est-ce que Lisp a de plus à ce niveau? J'ai beaucoup de problème avec la synthaxe du LISP (et j'ai très peu d'expérience en programmation fonctionnelle), mais c'est vrai que je ne me suis pas acharné non plus. Je vais étudier cela de plus près.Citation:
Le seul langage qui respecte le flux de programmation… c’est le Lisp et ces dérivés… Pratiquez-le un peu (et même beaucoup) et vous connaîtrais les contraintes d’un respect des flux…
Meilleures salutations
Thierry
entierement d'accord avec cette regle goto est une aberation..Citation:
Envoyé par argoet
bon dsl j'ai pas tout lu donc ça a peut etre deja été dit, mais il y a toujours l'argument d'autorité :
Dijkstra a dit que goto c'est mal :
http://www.acm.org/classics/oct95/
Et moi je lui fait confiance :)
Ca c'est tout de même limité comme réflexion. Il faut se méfier des gourous et de leurs dogmes. En l'occurence, tu fais bien de lui faire confiance.Citation:
Dijkstra a dit que goto c'est mal :
http://www.acm.org/classics/oct95/
Et moi je lui fait confiance
Thierry
hm c'est pas si limité que ça, Dijkstra est un chercheur connu, et je m'appuis sur ses résultats... c'est une démarche courante :)
C'était juste la façon dont tu l'a dit! Je ne met pas en doute ses dires, d'autant plus que je suis d'accord.
Salutations
Thierry
Personellement j trouve que goto est indique pour resoudre uncertain nombre de problemes et notament ceux de saut d'instruction et j ne comprend pas non plus pourquoi elle sucite tant de crainte. une fois qu'on sait comment ca marche ce n'est plus du tou illisible je trouve.
je pense su'on doit profiter des avantages de la programmation structuré et ne pas abusé des goto.Car sutout pr les gens qui ont deja programmer en assembleur on peut simuler des tests des boucles jsute avec les gotos et le code et ne pas du tout claire et s'est en plus en plus difficile pr le maintenir ou le corriger.
Bon, vu mon pseudo, je ne peux pas ne pas me mêler au débat. Vous l'aurez compris, j'ai fait du basic et de l'assembleur (donc, je suis définitivement perdu pour l'informatique, dirait mon prof).
Est-ce que les anti-gotos pourraient me dire comment faire le programme suivant sans goto ?
Soit le programme VHDL suivant (pas de panique, même si vous ne connaissez pas le VHDL, vous comprendrez quand même):
Le VHDL est fait pour décrire des composants indépendants, donc chaque procédure tourne en parallèle.Code:
2
3
4
5
6
7
Je voudrais faire un programme C (séquentiel, donc) qui simule ces composants. J'ai donc une fonction principale qui appelle chaque procédure alternativement. Sur le "wait on A", la procédure redonne la main à la boucle principale (donc un return), puis doit continuer le traitement à l'endroit où elle s'est interrompue quand le signal A (une variable globale, pour simplifier) est modifiée. Ca donne ceci en c:
Je ne vois pas bien comment faire ce type de programme sans gotos, à moins de faire autant de threads que de procédures, sachant qu'on va vite être limité par le nombre maxi de threads autorisés par le système.Code:
2
3
4
5
6
7
8
9
10
Mais je suis sûr que les anti-gotos vont me donner une solution élégante, structurée, et sans gotos...
Argh ! Je suis repéré !Citation:
Envoyé par 10_GOTO_10
Citation:
vont me donner une solution élégante, structurée, et sans gotos...
Trop simple. j'ai sans doute rien compris...Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
Oui, c'est pas si simple: le wait peut être inclus dans des boucles et/ou dans des if (c'est à dire que le begin du if est dans Traitement et le end du if est dans SuiteTraitement). Il peut aussi bien sûr y avoir d'autres wait à d'autres endroits.
Je ne vois pas en quoi goto aide. Si j'ai bonne memoire, on ne peut pas faire de goto vers l'interieur de structure de controle en C (ou bien est-ce uniquement en C++?).Citation:
Envoyé par 10_GOTO_10
De toute maniere pour implementer l'equivalent de wait, il te faut des coroutines puisqu'il peut y avoir toutes les variables de la pile d'appel a stocker. Si tu veux le gerer en C, il faut faire pas mal de chose a la main. Tellement que j'aurais tendance a definir un preprocesseur specialise pour ca, ou a tout le moins une lib complete bien pensee ce qui serait aussi du boulot. Pourquoi ne pas utiliser un vrai simulateur VHDL? Ou Verilog. Ou System C.
Heu, oui. je suis effectivement en C++. Ca ne change rien au débat.Citation:
Envoyé par Jean-Marc.Bourguet
Non, en VHDL toutes les variables sont statiques (on ne peut pas créer un bout de fil dans un composant et le détruire). J'espère qu'il n'y a pas de spécialiste VHDL dans le forum, je ne suis pas absolument sûr de ne pas dire une bêtise.Citation:
Envoyé par Jean-Marc.Bourguet
Alors celle là elle n'est pas mal: "N'UTILISEZ PAS DE GOTO !!! CHANGEZ DE COMPILATEUR AU BESOIN, MAIS SURTOUT N'UTILISEZ PAS DE GOTO !!!"Citation:
Envoyé par Jean-Marc.Bourguet
Je faisais allusion au fait qu'en C++ on ne peut pas faire de goto après une déclaration (et je me trompais car je pensais qu'on ne pouvais pas entrer dans un bloc quel qu'il soit). Ca montre que j'utilise peu les goto. Très peu.Citation:
Envoyé par 10_GOTO_10
Tu peux avoir des variables dans les fonctions et les procédures. Mais je ne sais plus si tu peux avoir des wait dedans (cela fait un peu trop longtemps et j'ai surtout fait de la synthèse RTL où la syntaxe est plus contrainte qu'en simulation; en synthèse RTL, tu ne peux avoir qu'un wait par process et ce doit être le premier statement du process.).Citation:
Envoyé par 10_GOTO_10
C'est plus que changer de compilateur, c'est changer de language. Utiliser un language adapté plutôt qu'un avec lequel il faut bricoler pour manipuler les concepts, ça me semble être la base.Citation:
Alors celle là elle n'est pas mal: "N'UTILISEZ PAS DE GOTO !!! CHANGEZ DE COMPILATEUR AU BESOIN, MAIS SURTOUT N'UTILISEZ PAS DE GOTO !!!"Citation:
Envoyé par Jean-Marc.Bourguet
Les goto ne me gène pas. Je vais les utiliser s'ils correspondent à mon besoin. Je vais les utiliser pour bâtir la primitive adéquate. Mais je ne vais pas m'acharger à utiliser un langage qui ne propose pas la primitive sur laquelle toute ma conception est bâtie. Si je ne manipule que des coroutines, j'utiliserai un langage avec des coroutines, si je ne manipule que des machine d'états, j'utilise un générateur qui prend une description de machine d'états. Ou alors je bâtit ou j'utilise une bibliothèque de manipulation de coroutine ou de machine d'états (ce qui revient à utiliser un langage, la frontière entre les deux est fort poreuse). Si je n'ai qu'une routine, qu'une machine d'états, oui là je vais utiliser des goto de manière locale (encore que pour des coroutines, je crois qu'un switch est plus adapté).
C'est uniquement ce que je voulais dire à travers cet exemple (peut-être pas très bien choisi, j'aurais pu choisir un autre language, on est d'accord).Citation:
Envoyé par Jean-Marc.Bourguet
Je voulais seulement répondre aux inté... heu, intransigeant du C qui édictent des règles absolues, "les char *, c'est mal", "les goto, on peut toujours s'en passer", etc, etc. l'informatique en général et un language en particulier, c'est un outil. Il faut en utiliser les fonctionnalités qu'ils offrent, de la meilleure façon pour chaque cas, mais sans a priori sur la façon de faire. L'important est: 1) que ça marche. 2) que ce soit clair pour celui (sans doute soi-même) qui va le relire.
je vais rajouter 3/ que ça nuit pas à la securité
il est vrai qu'à une epoque on ne pouvait pas s'en passer (mon vieux basic :p), mais maintenant en C/C++, tout peut se faire sans goto en ameliorant le code et sa securité.
Alors pourquoi vouloir continuer à l'utiliser ?
Enfin bon je l'utilisais quand j'etais très jeune sur les vieux langages de programmation, mais ensuite quand on m'a appris a programmer en C, on m'a toujours banni de les utiliser sous peine d'être flagelé :lol:
Salut,
J'ai plusieurs fois était confronté a ce genre de problème en reprenant du code existant, et en voulant supprimer les 'goto ERROR' (qui ne gêné que moi entre autre!) ...
Une solution est de decouper la fonction:
Le code de base n'est pas suffisamment clair... on doit pourvoir le faire en une seule fonction je comprend que l'on est dans une boucle ?Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
un essai:
Mais bon... a chacun ces méthodes de codage, l'essentiel c'est d'être assez clair pour des évolutions ou des corrections de Bugs et ça aussi bien par qq'un d'autre.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Le goto peut etre tres pratique mais doit etre utilisé avec soin. Il est notamment tres pratique pour la gestion d'erreur. Il permet notamment de creer un bloc pour les gestions d'erreurs et de centraliser la desallocation de ressources sur sortie d'erreur. En cas d'erreur il suffit de faire un goto sur un label a la suite duquel on procede à la desallocation et à la sortie de fonction. Cependant une regle pratique est d'éviter de faire un goto qui remonte le flot d'instruction, ce qui peut conduire a des cas délicats.