Discussion :

[Coriolan]

Trolldi : GOTO est formidable, elle permet d'accélérer 2 à 3 fois la vitesse d'exécution du code
Que pensez-vous de son utilisation ?

Goto est une instruction héritée des premiers langages informatiques, époque où certaines instructions très connues actuellement n’existaient pas, comme les boucles et les structures de contrôle. Néanmoins, même à l’âge moderne de l’informatique et après avoir été décriée par plusieurs informaticiens de renom, cette instruction est encore utilisée, et cela même au sein des géants de l’informatique comme Apple ; à titre d’exemple la recherche du mot-clé goto sur un portail tel que GitHub débouche sur des millions de résultats.

« Je peux soit restructurer le code ou utiliser une petite GOTO à la place. Tant pis, ça ne peut pas être si terrible que ça, goto main_sub3; »

Depuis les 1970s, les programmeurs modernes ont commencé à rejeter cette instruction, sous le motif qu’elle rend les programmes plus difficiles à comprendre et à maintenir (on parle dans ce cas de programmation spaghetti). Depuis lors, on a commencé à recourir à des structures comme les conditionnelles (if .. then .. else ..) ou les boucles (for, while, etc.) qui font partie intégrante de tous les langages de programmation impératifs modernes.

Edsger Dijkstra et Niklaus Wirth ont défendu l'idée selon laquelle l'instruction goto ne peut que mener à du code illisible. D'autres, comme Linus Torvalds ou Robert Love, ont fait remarquer que même si elle incite à produire du code spaghetti, l'instruction goto peut être appréciable et rendre au contraire le code plus lisible, lorsqu'elle est employée à bon escient.

Alors dans quel cas cette instruction est-elle encore utilisée ? Parmi les cas de figure évoqués existent la sortie d’une boucle imbriquée ce qui épargne le recours à plusieurs break, l’amélioration de la lisibilité du code et le traitement des erreurs ou encore l’optimisation manuelle du code pour améliorer les performances.

Dans les deux premiers cas, toute utilisation parcimonieuse semble correcte, mais pas dans le dernier cas selon Jeff Law et Jason Merril, tous les deux ingénieurs chez Red Hat et membres du comité du compilateur GCC. En effet, ils expliquent que l’optimisation manuelle du code n’est plus à l’ordre du jour, car les compilateurs modernes sont suffisamment développés pour se charger gracieusement de cette tâche, en transformant le code en entrée en une série de blocs de base et en se reposant sur l’utilisation d’un graphe de flot de contrôle (GFC). Résultat des courses aucune distinction entre un code bien structuré et un code en spaghetti (qui résulte d’une addiction au goto).

Maintenant dans le monde réel, RASTER montre comment l’instruction GOTO peut être utile quelques fois.

Code c :

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

1
2
3
4
5
6
7
8
if (shared) lock();
if (data == INVALID) {
  log_error("blah %s:%i %s() -> %p\n", __FILE__, __LINE__ __FUNC__, data);
  return NULL;
}
// smallish body of code hunting through some nested tables using data
if (shared) unlock();
return realdata;

lock() et unlock() sont déclarées static inline pour faciliter la vérification d’erreurs et le logging et aussi pour faciliter la vie au développeur. Alors if(shared) lock(); devient :

Code c :

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

1
2
3
4
5
6
7
if (shared) {
  if (lock == VALID) {
    if (!do_lock(lock)) {
      log_error("lock fail %s:%i %s() -> %p\n", __FILE__, __LINE__ __FUNC__, lock);
    }
  }
}

La même chose pour unlock().



Maintenant ce code devrait verrouiller une ressource partagée, aller chercher quelques données et possiblement les déverrouiller et les retourner tout en manipulant les erreurs au passage. Raster s’est rendu compte que ce segment de code consommait entre 6 et 7 % du CPU, ce qui fait un peu beaucoup.


Alors il a passé un peu de temps à réorganiser tout ça :

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
if (shared) {
  lock();
  if (data == INVALID) {
    log_error("blah %s:%i %s() -> %p\n", __FILE__, __LINE__ __FUNC__, data);
    return NULL;
  }
  // smallish body of code hunting through some nested tables using data
  unlock();
} else {
  if (data == INVALID) {
    log_error("blah %s:%i %s() -> %p\n", __FILE__, __LINE__ __FUNC__, data);
    return NULL;
  }
  // smallish body of code hunting through some nested tables using data
}
return realdata;

Malgré cela, l'usage du CPU utilisé est resté le même (6-7 %). Raster s’est rendu compte que le locking est coûteux en ressources. Alors il a décidé de recourir à l’instruction GOTO pour gérer les exceptions qui sont rares, en transférant ces cas à la fin de la fonction, pour laisser place aux autres cas plus communs. Cette manoeuvre lui a permis de réduire les pertes de cache.

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
if (!shared) {
  if (data != INITIALIZED) goto doinit_shared;
  doinit_shared_back:
  if (data == INVALID) goto err_invalid;
  // smallish body of code hunting through some nested tables using data
} else {
  lock();
  if (data != INITIALIZED) goto doinit_shared;
  doinit_shared_back:
  if (data == INVALID) goto err_invalid;
  // smallish body of code hunting through some nested tables using data
  unlock();
  return realdata;
}
return realdata;
doinit_shared:
  // a few lines of initting data here
  goto doinit_shared_back;
doinit:
  // a few lines of initting data here
  goto doinit_back;
err_invalid:
  log_error("blah %s:%i %s() -> %p\n", __FILE__, __LINE__ __FUNC__, data);
  return NULL;

Et voilà, l’usage du CPU est tombé à 2,5 % soit 2 à 3 fois la vitesse initiale.


En gros, Raster pense que rien n’est complètement méchant, bien sûr il ne faut pas utiliser GOTO pour remplacer les boucles et les structures de contrôle. Mais pour déplacer le code loin du hot path et manipuler les exceptions, Raster pense que c’est admissible et ça permet de rendre le code plus lisible et fournit surtout une performance accrue qui passe par dessus toute laideur perçue dans le code.


Source : Rasterman

Et vous ?

Qu'en pensez-vous ?

[Médinoc]

Plus simple: programmez en GOTO++.

[Florian_PB]

Il m'arrive d'utiliser GoTo avec certains langages où il existe une gestion des erreurs mais aucun Try Catch (VBscript par exemple).

[ZwQuery]

goto fail;
goto fail;

[esperanto]

En premier lieu je ne vois pas pourquoi son code serait plus rapide que ceci:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
if (!shared) {
  if (data != INITIALIZED) { // a few lines of initting data here (1) }
  if (data == INVALID) { log_error("blah %s:%i %s() -> %p\n", __FILE__, __LINE__ __FUNC__, data); return NULL; }
  // smallish body of code hunting through some nested tables using data
} else {
  lock();
  if (data != INITIALIZED) { // a few lines of initting data here (2) }
   if (data == INVALID) { log_error("blah %s:%i %s() -> %p\n", __FILE__, __LINE__ __FUNC__, data); return NULL; }
  // smallish body of code hunting through some nested tables using data
  unlock();
  return realdata;
}
return realdata;

à la limite, si la partie "// a few lines..." est suffisamment longue, il faut la remplacer par une procédure inline statique pour éviter d'avoir à la répéter. D'autant plus que l'auteur dit vouloir faire ça pour "déplacer le code loin du hot path", ce qu'une procédure inline permet justement de faire.

En plus de ça le code initial a deux étiquettes nommées doinit_shared_back: donc j'ai même du mal à comprendre comment ça peut fonctionner.

Maintenant, concernant l'usage du GOTO en général, même si j'ai toujours réussi à l'éviter, je pense que ce qui nuit à la lisibilité du code, c'est moins l'usage d'un goto que d'une procédure à rallonge. Et comme la programmation spaghetti se fait sans procédure, le code est forcément à rallonge.

Le plus souvent quand on apprend aux programmeurs à se passer du goto, c'est en remplaçant

Code :

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

1
2
3
4
if (une-condition) goto fin;
     // quelque chose de très très long
fin:
    // suite

par

Code :

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

1
2
3
4
if (! une-condition) {
     // quelque chose de très très long
}
    // suite

alors que ce qui rendrait vraiment le code plus lisible, c'est de déplacer "quelque chose de très long" par une procédure, fut-elle inline si les performances sont tellement cruciales. Même si elle n'est appelée qu'une seule fois dans le code, le seul fait de lui choisir un nom et des paramètres explicites est déjà une documentation du code en soi.

bien sûr il ne faut pas utiliser GOTO pour remplacer les boucles et les structures de contrôle.

Moi j'ai vu pire : un collègue qui utilise des boucles pour remplacer le goto. C'est à dire que pour la dernière instruction que j'ai écrite, lui choisira ceci :

Code :

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

1
2
3
4
5
boucle: do {
     if (une-condition) break boucle;
     // quelque chose de très très long
} while (0);
    // suite

Comme ça il satisfait ses profs qui lui ont dit "pas de goto" (mais visiblement sans expliquer pourquoi).
Évidemment ça fonctionne puisque la boucle est exécutée une fois maximum à cause du while(0). Mais pour la lisibilité, on repassera

[MikeRowSoft]

Pour Delphi et C++ Builder, une fois la VCL retiré ben oui, 6 à 7 % c'est beaucoup.

Que dire des consoles de jeux 8 bits et 16 bits ?

[MikeRowSoft]

Il m'arrive d'utiliser GoTo avec certains langages où il existe une gestion des erreurs mais aucun Try Catch (VBscript par exemple).

Il y a aussi quelques langages de calculatrices et bien sur le langage assembleur.

[CS FS]

J’ai trois lourds secrets. Et le second c’est que j’ai déjà utilisé un goto en C#, une fois, UNE SEULE FOIS... sur le coup, j’ai même trouvé la solution élégante. Ça donnait un truc du style :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
switch (status)
{
    case Status.Initialisation:
        db.Init();
        goto case Status.BlaBla;
    case Status.BlaBla:
        // Du code, du code, du code.
        break;
    case Status.BlaBla2:
        // Du code, du code, du code.
        break;
}

Ça c’est certainement parce que j’ai passé mon enfance à coder en Basic et que j’ai mangé du goto et du gosub à outrance. Et comme le conclu parfaitement une étude bullshit, ce langage du diable a corrompu mon cerveau à jamais...

[Squisqui]

sur le coup, j’ai même trouvé la solution élégante. Ça donnait un truc du style :

Je crois que l'exemple n'illustre pas les bienfaits de ton lourd secret

[CS FS]

Je crois que l'exemple n'illustre pas les bienfaits de ton lourd secret

Pour ma défense j'étais jeune et insouciant (des lignes de code ont coulé depuis... en outre, je ne me souviens plus du cas de figure exact qui m'avait poussé à réaliser cet acte hérétique).

[el_slapper]

Nan, mais le mal, ce n'est pas le GOTO seul, c'est quand on le farçit d'un alter proceed :

COBOL offrait la possibilité de modifier du code pendant l'exécution à l'aide de la fameuse instruction ALTER X TO PROCEED TO Y (altérer X pour aller vers Y). Cette possibilité dangereuse, qui transposait une technique courante de la programmation en langage machine, a été éliminée des spécifications du langage. Rendant possible la modification à la volée de l'exécution d'un programme, cette commande permettait d'outrepasser des ordres GO TO, complexifiant ainsi la maintenance.

En d'autres termes, j'ai un ALTER TRAITEMENT-2 TO PROCEED TO TRAITEMENT-3, et GOTO TRAITEMENT-2 m'emmène directement à TRAITEMENT-3.

Très performant.

Très suicidaire, surtout. Celui qui fait ça, il a 6 étages pour apprendre à voler.

[ijk-ref]

Pour les boucles imbriquées, je me demande toujours pourquoi n'existe-il pas simplement un "break n" pour quitter directement 'n' boucles. POURQUOI §§§

Ca devient vite moche un 'switch' dans une boucle. Afin AMHA l'instruction 'switch' est inadaptée pour des usages modernes comme en c#. Je préfèrerais une gestion plus classique des 'cas' comme un "elsecase(cond){}" plutôt qu'un 'label' et son 'break'

[23JFK]

goto est l'équivalent assembleur de l'instruction JMP qui est l'une des commandes les plus utilisées dans un code exécutable. Par ailleurs, l'optimisation d'un code source par le compilateur repose largement sur l'ajout de JMP dans le code exécutable alors ce ne sont pas quelques goto pas trop mal placés dans le code source qui vont altérer la performance finale du code exécutable optimisé. Pour s'en convaincre, il suffit de désassembler un code exécutable issu d'une compilation optimisée à partir d'un fichier source qui n'utilise aucun goto pour constater que cela génère tout le temps du code spaghetti.

[CS FS]

Afin AMHA l'instruction 'switch' est inadaptée pour des usages modernes comme en c#. Je préfèrerais une gestion plus classique des 'cas' comme un "elsecase(cond){}" plutôt qu'un 'label' et son 'break'

En C# on va bientôt pouvoir faire ça :

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(shape)
{
    case Circle c:
        WriteLine($"circle with radius {c.Radius}");
        break;
    case Rectangle s when (s.Length == s.Height):
        WriteLine($"{s.Length} x {s.Height} square");
        break;
    case Rectangle r:
        WriteLine($"{r.Length} x {r.Height} rectangle");
        break;
    default:
        WriteLine("<unknown shape>");
        break;
    case null:
        throw new ArgumentNullException(nameof(shape));
}

Mais c'est un peu HS...

[joublie]

Répondre au sondage par " je refuse de voter pour ce sondage idiot " est contradictoire...

[esperanto]

Pour les boucles imbriquées, je me demande toujours pourquoi n'existe-il pas simplement un "break n" pour quitter directement 'n' boucles. POURQUOI §§§

ça pourrait être dangereux : si tu écris une boucle et que plus tard tu la déplaces dans une procédure, le nombre de boucles que tu peux sauter va changer.
alors qu'un label, tu n'es pas obligé de le renommer : si j'ai écrit "break boucle1;" alors ça termine toujours la même boucle, même si je l'ai déplacée (ou si je l'ai déplacée à un endroit où le label est hors de portée, le compilateur me le signale et ça fait partie de son rôle)

Afin AMHA l'instruction 'switch' est inadaptée pour des usages modernes comme en c#. Je préfèrerais une gestion plus classique des 'cas' comme un "elsecase(cond){}" plutôt qu'un 'label' et son 'break'

Là je suis assez d'accord, je ne comprends pas bien pourquoi ils ont autorisé en C le fait que les instructions d'un "case" puissent se continuer sur le suivant. Bien sûr on sait tous que ce sont des goto après la compilation, mais dans presque tous les langages non dérivés du C, les blocs d'un "case", même s'ils portent un autre nom, sont strictement indépendants. Et l'argument disant que ça permet d'en avoir plusieurs qui se suivent (case 1: case 2:) n'est pas convaincant car rien n'interdirait une syntaxe du type "case 1, 2:" voire "case 1..2:" ce qui serait même bien plus pratique.

[Squisqui]

Pour ma défense j'étais jeune et insouciant (des lignes de code ont coulé depuis... en outre, je ne me souviens plus du cas de figure exact qui m'avait poussé à réaliser cet acte hérétique).

Je ne parle pas d'insouciance, je suis sûr que tu as trouvé le moyen de devoir faire un goto dans un switch sans que ce soit une gestion d'erreur.
C'est plutôt l'exemple de pseudo-code qui m'a fait sourire. Pour passer d'un case au suivant, l'absence de break suffit largement (ce que tu as fait). L'instruction goto ne sert strictement à rien. Si c'était un code compilable en C, je suis sûr que l'assembleur généré serait identique.

[CS FS]

C'est plutôt l'exemple de pseudo-code qui m'a fait sourire. Pour passer d'un case au suivant, l'absence de break suffit largement (ce que tu as fait). L'instruction goto ne sert strictement à rien. Si c'était un code compilable en C, je suis sûr que l'assembleur généré serait identique.

Ah ok.
Alors non (mais c’est ma faute, je n’ai pas précisé), le code qui illustre mon exemple est censé être écrit en C#. En l’occurrence, si dans ce magnifique code tu vires le goto, ça ne compile plus (c’est justement tout "l’intérêt" du goto =P).

[Mingolito]

Répondre au sondage par " je refuse de voter pour ce sondage idiot " est contradictoire...

T'es un petit malin, ca veux dire que tu à au moins 70 de QI
Encore un effort et si tu passes au dessus des 110 de QI tu risques même de comprendre l'humour
Et soyons fou, peut être même qu'un jour tu risques de comprendre ce que le mot Trolldi peut bien vouloir dire

[ijk-ref]

En C# on va bientôt pouvoir faire ça :

Code :

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

1
2
3
4
5
6
7
8
9
switch(shape)
{
    case Circle c:
        WriteLine($"circle with radius {c.Radius}");
        break;
    case Rectangle s when (s.Length == s.Height):
        WriteLine($"{s.Length} x {s.Height} square");
        break;
   (...)

Mais c'est un peu HS...

Je sais C'est une nouvelle fonctionnalité fort pratique... mais je continue à penser que l'avoir implémenter sous la forme d'un switch classique est un très très mauvais choix.

ça pourrait être dangereux : si tu écris une boucle et que plus tard tu la déplaces dans une procédure, le nombre de boucles que tu peux sauter va changer.
alors qu'un label, tu n'es pas obligé de le renommer : si j'ai écrit "break boucle1;" alors ça termine toujours la même boucle, même si je l'ai déplacée (ou si je l'ai déplacée à un endroit où le label est hors de portée, le compilateur me le signale et ça fait partie de son rôle)

Ce n'est pas plus dangereux que de déplacer l'intérieur d'une boucle (avec un 'break' classique) dans une procédure : Le compilateur te prévient.
Tout comme il le ferait en lui précisant de sauter trois boucles avec un "break 3" ('3' ici n'est pas une variable)

Et puis je ne comprends pas bien ton exemple car il y autant de cas (si ce n'est plus) où tu souhaites en copiant des sauts 'relatifs' et non 'absolus' c'est à dire que tu ne souhaites pas forcement sauter au même endroit.

Là je suis assez d'accord, je ne comprends pas bien pourquoi ils ont autorisé en C le fait que les instructions d'un "case" puissent se continuer sur le suivant. Bien sûr on sait tous que ce sont des goto après la compilation, mais dans presque tous les langages non dérivés du C, les blocs d'un "case", même s'ils portent un autre nom, sont strictement indépendants. Et l'argument disant que ça permet d'en avoir plusieurs qui se suivent (case 1: case 2: ) n'est pas convaincant car rien n'interdirait une syntaxe du type "case 1, 2:" voire "case 1..2:" ce qui serait même bien plus pratique.

Après on peut excuser le C par son grand age et le C++ pour la compatibilité mais il est difficile ensuite (comme tu dis) de comprendre cette infamie sur un langage moderne tel le C#