Discussion :

[Emmanuel Delahaye]

Mais puisque JMP et compagnie en ASM ça équivaut au goto Basic donc n'importe quel exe que tu désassembles ça ressemble à un foisonnement de goto , non ???

Dans beaucoup de cas, oui.

C'est idiot non ?

Non, c'est lié aux langages machines qui sont ce qu'il sont. Une machine 'raisonne' en saut et non en action.

Moralité des courses tu fais un beau programme structuré dans un langage très évolué et bien structuré avec des modèles conceptuels de données pour avoir au bout du compte .......3 millions de lignes de goto C'est c.. alors l'informatique

Non, c'est normal. Je pense qu'il n'existe pas pour le moment de langage machine structuré, et, à moins qu'on démontre que c'est plus efficace autrement, ce n'est pas près de changer. (Le bytecode Java, c'est structuré ?)

[Mac LAK]

Moralité des courses tu fais un beau programme structuré dans un language très évolué et bien structuré avec des modèles conceptuels de données pour avoir au bout du compte .......3 millions de lignes de goto

C'est à la fois beaucoup plus complexe et beaucoup plus simple que ça : un "continue" C est certes un "JMP" déguisé.
Un "vrai" jump ASM ne t'interdit ABSOLUMENT PAS de sauter carrément au MILIEU d'une instruction ASM (j'te racontes pas la tronche du processeur après un coup pareil, cependant !! ).
Un "continue", par contre, est garanti par le compilateur, sa grammaire et son module de traduction comme étant fiable, c'est à dire que la destination du saut est garantie correcte. Bref, le saut est "sécurisé".

Le bytecode Java, c'est structuré ?

Bien sûr que non, à moins que l'instruction CALL soit désormais considérée comme une CNS de structuration du langage...

[Trap D]

Moralité des courses tu fais un beau programme structuré dans un langage très évolué et bien structuré avec des modèles conceptuels de données pour avoir au bout du compte .......3 millions de lignes de goto C'est c.. alors l'informatique

Je trouve plutôt que c'est à la fois génial et triste, génial car c'est un programme qui te fais ça automatiquement et triste car ta belle construction intellectuelle se réduit finalement à suite de branchements.

[mat.M]

rien à voir mais c'est un peu comme l'existence , de savoir que de poussière de matière on retourne à l'état de poussière de matière
Comme le chante Etienne Daho "du berceau à la tombe c'est pareil pour tout le monde "

[bster]

C'est une erreur de faire un goto parceque une fois compilé les jne jnz jz jmp etc...etc...y'en a vraiment pas mal sans compter les sauts qui ne sont pas définis de façon directe (nécessitant une suite d'instructions et d'adressages) sont tous des saut conditionnels sauf jmp et call, et ceux si sont des sauts d'adresses dans la mémoire lorsque le programme est chargé "executé". J'en ai bouffé assez d'assembleur pour le savoir (sur 6809, sur 69xxx, sur x86, sur Z80 sur z81 etc...) quand j'étais en éléctronique notement.
un goto c'est mal aussi parceque c'est un saut au niveau algorythmique c'est à dire avant même toute programmation. et pas materiellement nécéssaire. troisiemement un programme utilisant des sauts à ce niveau en cas de bug il se retrouve à un endroit totalement aléatoire de la mémoire (y compris dans un autre programme aussi chargé) et continue à lire le code et l'executer comme si il etait au bon endroit et là bonjour les concéquences ! cequi n'arrive pas dans une fonction ou une procedure car ça plante la procédure ou la fonction retourne une erreur et point, on peut même la prévoir et la gérer dans une certaine meusure. quatriémement la maintenance la mise à jour ou les ajouts ou encore plus vrai le debuggage d'un programme utilisant plus de 2 ou 3 gotos devients un enfer en cas de pépin. Surtout si tu n'as qu'une log ou un core pour retrouver l'erreur du programme !

[Stef_D]

Je suis pas aussi catégorique quant à l'utilisation du GOTO en C (après lu tout le topic je me rend compte que je répète ce qui a déjà été dit ).
Certes c'est moche, ça casse la structure d'un algo et derrière ça casse les optimisations du compilo etc...

Mais bon récement j'ai fais plusieurs programmes où j'ai utilisé du goto à gogo (un émulateur 68000 et Z80), et c'est grâce à cette méthode que j'ai pu obtenir les meilleurs performances (notament grâce aux "computed label" pour le 68000).

C'est vrai qu'au niveau structure c'est moche, mais dans des soucis d'optimisations (vitesse et taille de code), le GOTO peut vraiment aider, et dans mon cas réellement je ne pouvais pas m'en passer (si quelqu'un peut me prouver le contraire, je suis preneur ^^).

Selon la règle de Dijkstra (Dijkstra observed that the quality of a programmer's code was inversely proportional to the number of gotos the programmer used) je dois être un mauvais codeur :p

[rod59]

[Nouveau thread fusionné au debat le 06-12-2005 par netah25]

bonjour à tous,
je voudrai savoir ce que vous pensez des boucles goto ?
Est que son utilisation est signe de mauvais algorythmes?
Merci d'avances
Rod

[fearyourself]

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...

[Trap D]

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.

[Rémiz]

Disons qu'il faut l'utiliser avec modération.

Dans les boucles, il peut être utilisé à la place du break. Personellement je trouve que :

Code :

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

1
2
3
for(x=0; x<100; x++)
    if (val == tab[x])
        goto FinRecherche

est plus parlant que :

Code :

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

1
2
3
for(x=0; x<100; x++)
    if (val == tab[x])
        break;

[Edouard Kaiser]

Dans ce cas à la place du "for" autant faire un "while" est on évite encore ces break ou goto assez moche

[diogene]

Rémiz :

Code :

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

1
2
3
for(x=0; x<100; x++) 
    if (val == tab[x]) 
        goto FinRecherche

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à.
fearyourself :

Son utilisation rend l'algorithme difficilement comprehensible par un oeil externe (pareil que pour le break ou le continue)

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é

[Franck.H]

Moi perso, en plus de deux ans de C, jamais utilisé de goto ou de jmp

[Rupella]

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...

[Alexis75014]

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.

[Pirlouit260593]

Disons qu'il faut l'utiliser avec modération.

Dans les boucles, il peut être utilisé à la place du break. Personellement je trouve que :

Code :

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

1
2
3
for(x=0; x<100; x++)
    if (val == tab[x])
        goto FinRecherche

est plus parlant que :

Code :

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

1
2
3
for(x=0; x<100; x++)
    if (val == tab[x])
        break;

Pour ces codes, je préfère écrire de la façon suivante qui est plus lisible, plus parlant et plus concise.

Code :

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

for(x=0; x<100 && val != tab[x]; x++);

En fait en regardant bien les deux codes, on voit bien qu'il ne s'agit pas de la même conception.

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

[Newgaia]

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)

[vic]

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 :

Permier cas, traitement d'erreur. Exemple :

Code :

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
int fonction() {
    /* traitement 1 ... */
    if( <erreur> ) {
        /* nettoyage  */
        return <code_erreur_1>;
    }
 
    /* traitement 2 ... */
    if( <erreur 2> ) {
        /* nettoyage  */
        return <code_erreur_2>;
    }
 
    /* traitement 3... */
    if( <erreur 3> ) {
        /* nettoyage  */
        return <code_erreur_3>;
    }
 
    // etc ...
 
    /* nettoyage  */
    return <ok>;
}

Evidement on a un gros problème de code redondant, difficile à changer. On peut avantageusement le remplacer par la chose suivante :

Code :

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
int fonction() {
    int ret = <ok>;
 
    /* traitement 1 ... */
    if( <erreur> ) {
        ret = <code_erreur_1>;
        goto fin;
    }
 
    /* traitement 2 ... */
    if( <erreur 2> ) {
        ret = <code_erreur_2>;
        goto fin;
    }
 
    /* traitement 3... */
    if( <erreur 3> ) {
        ret = <code_erreur_3>;
        goto fin;
    }
 
    // etc ...
 
    fin:
    /* nettoyage  */
    return ret;

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.


Deuxième cas, pouvoir sortir rapidement d'une construction très complexe et remonter une erreur. Exemple :

Code :

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
while( <...> ) {
    /* traitements ...*/
    if( <...> ) {
        /* traitements ... */
    } else {
        /* traitements ...*/
        for( <...> ) {
            if( <...> ) {
                /* traitements ...*/
                if( <erreur> )
                    goto fin_while;
                /* traitements ...*/
            } else if( <...> ) {
                /* traitements ...*/
            } else {
                /* traitements ...*/
                if( <erreur> )
                    goto fin_while;
                /* traitements ...*/
            }
        }
        /* traitements ...*/
    }
    /* traitements ...*/
    fin_while:
}

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.

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.

[amaury pouly]

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é:

Code :

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
 
switch(...)
case
....
case
....
case
...
case <machin>
  if <truc>
     goto Lcase_truc
  else
    ....
case
...
case ..
Lcase_truc:
....

Là c'est vraiment particulier mais dans certaines circonstances mieux vaut ne pas faire autrement à mon avis

[koala01]

Salut,

Je suis surpris qu'un thread de pres de deux ans soit remonté, mais, je voudrais revenir sur une intervention déjà vieille:

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é:

Code :

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
 
switch(...)
case
....
case
....
case
...
case <machin>
  if <truc>
     goto Lcase_truc
  else
    ....
case
...
case ..
Lcase_truc:
....

Là c'est vraiment particulier mais dans certaines circonstances mieux vaut ne pas faire autrement à mon avis

Je suis aussi d'avis que le goto ne doit etre utilisé que de manière exceptionnelle (et pourtant, j'ai eu un prof qui menaçait de nous jeter par la fenetre si on l'utilisait ) mais, en y réfléchissant bien, une simple réorganisation du code présenté peut rendre le goto inutile dans ce cas...

Nous nous comprenons bien: on considère que l'étiquette Lcase_truc se trouve au tout début du case équivalent.
Dans ce cas, un code ressemblat à

Code :

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
 
switch(...)
case
....
case
....
case
...
 
case /* remonté pour que les deux cases impliqués soient successifs */
...
case <machin>
  if <truc>
  {
     ... /*gestion pre Lcase_machin */
    /* pas de break ici pour forcer l'exécution du case suivant*/
  }
  else
  {
        ....
        break;
  }
case ..
/* ici se trouvait Lcase_truc */
....

Je reste en effet persuadé que dans une grande partie des situations (hormis la remontée d'erreurs et autres cas très particuliers), il est tout à fait possible de faire sans utiliser les goto, et d'obtenir, malgré tout, un code tout aussi lisible et efficace...

La seule disposition à prendre étant, peut etre, de mettre un commentaire indiquant explicitement que le cas suivant est également effectué

N'oulions pas, en effet, que, si continue ou break peuvent etres considérés comme goto déguisé (car, de fait, ils ont les meme résultat... mais alors, toutes les instructions structurées peuvent etre considérées comme des goto...), le case pourrait etre, dans cette optique (que je ne partage pas forcément) comme... l'étiquette à laquelle fera référence le goto...

Maintenant, loin de refuser tout utilisation du goto, je préferes effectivement la limiter au stricte minimum (jusqu'à présent, j'ai toujours su faire sans )