Discussion :

[Christianchristian]

Bonjour,

Je pense que poser le problème du GOTO revient à poser le problème de la bonne ou mauvaise programmation.

années 1975 : Apparition des méthodes dites de "programmation
structurée". (par opposition à la programmation dite
linéaire : Utilisation plus ou moins intensive de l'ordre
GOTO).

Avant cette époque un pgm linéaire "mal monté" (avec une profusion d'ordres GOTO) était difficilement maintenable. Il n'était pas rare de devoir "le casser" pour le ré-écrire.
Par contre un pgm convenablement "monté" (peu d'ordres GOTO) par un programmeur ayant une approche structurée nécessairement personnelle était facilement modifiable.
L'arrivée des méthodes de programmation structurées a elle aussi généré certains excès. En effet pour éviter tout GOTO, certains programmeurs structuraient tellement leur programme (sous-prog appelant un sous-sous-prog appelant lui-même un sous-sous-sous-prog......) qu'ils obtenaient le résultat inverse de celui recherché. Leur pgm étaient tout aussi difficilles à maintenir pour peu qu'ils soient conséquents.
Ces deux attitudes illustrent peut-être le problème posé.
Les discussions sur le sujet étaient fréquentes et bien entendu les avis partagés et les positions fermement arrêtées.
Pour ou contre l'emploi du GOTO dans les pgm ?

En ce qui me concerne je n'ai pas banni cet ordre qui d'ailleurs s'impose plus qu'il ne se choisit. (en gardant à l'esprit que l'on peut toujours faire autrement, mais dans quelles conditions et à quel prix ?).
Par exemple :
Un test d'optimisation (IF) accompagné d'un GOTO, programmés au début d'un sous-prog et débranchant la logique d'exécution en fin du même sous-prog si la condition est remplie, me semble raisonnable. Cela permet bien souvent d'alléger la logique principale du pgm en ne l'encombrant pas avec des tests, qui sans être inutiles, n'intéressent pas directement cette logique et par le fait l'allourdissent.

A noter également que l'ordre GOTO est bien pratique lors de la mise au point d'un pgm, lorsque l'on souhaite "sauter" une séquence suspectée d'être à l'origine de l'erreur recherchée.

[Fabrice ROUXEL 1]

La solution est simple, imaginons très fort que cette instruction n'existe pas!

[Gruik]

La solution est simple, imaginons très fort que cette instruction n'existe pas!

Ca me ferait une belle jambe

[Invité]

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.

pour la gestion d'erreur, plutot qu'un "goto", j'aurais plutot tendance à créer une fonction englobant un exit() ou un return().

Pour moi, le goto est inutile :
chaque cas d'utilisation du goto montre que le bloc d'instructions à "sauter" pourrait/devrait être intégré dans une sous-fonction + mechanisme de test de l'appel.

Je pense qu'un usage du goto montre qu'on code avant d'écrire l'algo/la spec/etc ... et ça, c'est pas bien :p

il faut aussi se poser la question du "si j'ai besoin de mettre un goto, est-ce que ça n'est pas parce que mon pgm est mal construit ?"

[Blustuff]

Démontrer qu'on peut se passer du goto ne me semble pas difficile. A coup d'ajout de if et d'utilisation de variable supplémentaire, on y arrive. Pourtant cette démonstration devrait mettre la puce à l'oreille "On est obligés de créer des variable supplémentaire" et celà est d'autant plus gênant que ces variables n'ont pas de rôle algorithmique.

Code :

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

1
2
3
4
5
6
7
8
9
10
for (...)
{
  for (...)
  {
    ...
    goto FinDeBoucle;
  }
}
 
FinDeBoucle:

Ca, c'est parfaitement intuitif. Sortir d'un bloc, quelque soit son niveau est quelque chose d'intuitif, qu'on pourrait très bien écrire dans un algorithme mathématique désitiné à l'homme et non à la machine. Mais une chose m'a choquée dans les précédents arguments c'est qu'on ait pu insister dans ce genre de cas du fait que le code ne soit pas clair. Le goto ici a bien un avantage : on nomme la sortir de boucle, ce qui permet de comprendre son sens dans l'alogorithme. Toutefois nommer une boucle, c'est très facile. Dans un exemple de boucle non imbriquée :

Code :

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

1
2
3
4
5
for (...) // NomDeBoucleQuelconque
{
  ...
  break; // Fin de NomDeBoucleQuelconque
}

L'utilisation du goto dans le cas de blocs imbriqués est tellement intéressante qu'elle a été intégrée comme structure de langage dans certains langage de manière assez élégante :

Code :

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

1
2
3
4
5
6
7
{
  ...
  {
    ...
    break 2;
  }
}

Et là le sens que l'on veut donner à l'instruction est parfaitement clair. Une autre structure plus récente utilisée désormais dans de nombreux langages, et qui est accessoirement la plus puissante des structures conditionnelles est la gestion des exceptions. Ces aspects inexistants en C, il ne serait pas dérangeant d'utiliser dans ces cas précis, et uniquement ces cas, l'instruction goto.

Mais cela ne change rien au danger que représente le goto. L'argument a été répété de nombreuses fois, ce à quoi on a répondu "Ce n'est pas plus dangereux que malloc". Malloc est dangereux, lui aussi, et c'est pour cette raison que les langages les plus récents, non soucieux de la rapidité on préférer cacher au programmeur ces jouets défendus. On ne peut malheureusement pas se passer de l'allocation dynamique, mais on peut se passer de goto, ce qui pèse relativement lourd. On a des techniques pour sécuriser l'allocation de mémoire, des "habitudes" ou des "techniques" de programmation qui permettent de limiter les erreurs. On peut certainement trouver des règles de conduites à l'usage du goto qui permettent d'éviter les dangers.

"Ne jamais utiliser de goto" est une règle qui a ses qualités. C'est un peu comme le code de la route. On doit faire des vérifications inutiles, mettre le clignotant même quand on est tout seul sur la route. Cela a de nombreux avantage en fin de compte.

• Etant donné que le débat est compliqué et que tout le monde ne le lira pas, les absents ou ceux qui lisent en diagonal ne comprendront certainement pas les réels dangers et les réels intérêts du goto, et ne connaîtront donc pas les "bonnes" utilisations du goto que ce débat pourra détacher. En conséquent, mieux vaut ne pas les utiliser du tout.
  
  
• On se pose beaucoup de questions quand on programme. Est-ce que le temps perdu à se poser des questions en vaut le bénéfice ? Est-ce que le temps qu'on passe à se demander si on utilise un goto ou non en vaut le code obtenu ? Parfois non, l'usage du goto est clair, ou au contraire, la non utilisation de goto ne complique pas le code. Très souvent sur ce sujet, j'ai vu des solutions avec goto horriblement compliquées et l'auteur aurait, je pense, tout à fait gagné à "programmer sans réfléchir sans goto".
  
  
• Les raisons qui poussent à utiliser ou non un goto sont plutôt complexe. En ce qui me concerne, je n'arriverai pas à les mettres toutes dans ma mémoire. La où c'est ennuyeux c'est pour les dangers du goto. Si je n'arrive pas à me souvenir de tous les dangers du goto (et ils sont trrrès nombreux) il m'arrivera un jour de faire une connerie avec. Autant l'éviter.

Le principal désavantage du goto est de ne pas être clair du point de vue algorithmique. Coder dans son coin des applications brouillon de quelques centaines de lignes, ce n'est pas très grave. Coder tout seul sur des projets un peu ambitieux, ou coder sur un projet où l'on est pas seul, l'usage d'un code qui n'est pas compréhensible au premier coup d'oeil devient tout de suite gênant. Et le goto a cette mauvaise idée de ne pas toujours être compréhensible au premier coup d'oeil. Sur une fonction de dix ligne, un goto interne à la fonction ne posera pas trop de problème de compréhension. Sur des fonctions un peu complexes, ou en utilisant des labels peu explicites, on arrive très vite à devoir se creuser la tête pour comprendre ce qui est écrit. C'est très traitre quand on débute en programmation et que l'on veut se lancer dans un projet. Quand on programme on a tout ce que l'on veut en tête, on sait ce que l'on fait. Et deux mois plus tard, on peut revenir sur quelque chose que l'on a écrit et ne plus rien comprendre. Se faire peur une fois suffit en général.

Remplacer le goto par une structure aproprié a un avantage capital déjà précédement énnoncé. On ne sait pas comment il est possible d'arriver à un label donné. Par contre on sait très bien quand l'identation est claire, où un bloc commence et où il s'arrête. L'utilisation des blocs de code permet de voir au premier coup d'oeil la structure d'une portion de code, ce que ne permettent pas les goto. Et c'est son principal défaut.

Il existe des branchements compliqués auxquels on a certainement tous été confrontés une fois. Une sorte de faiblesse du langage algorithmique qui oblige la répétition de code, où ce qui est mieux, l'usage de fonction. (Qui n'est pas toujours aisé étant donné qu'il faut passer un certain nombre, parfois handicapant, de paramètres)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Si Condition1
| ...
| Aller à A
...
Si Condition2
| ...
| Aller à B
...
A:
...
B:

(J'espère que je ne me trompe pas)

Code :

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

1
2
3
4
5
6
7
Si Condition1
| Instructions1
| Aller à A
 
Instructions2
 
A:

est un truc qu'on a appellé

Code :

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

1
2
3
4
Si Condition 1 Alors
  Instructions1
Sinon
  Instructions2

Ici, ce qui pose problème est l'enchevetrement. En analysant les schémas d'exécution

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
Si Condition1
| Instructions1 
| Aller à A
 
Instructions2
 
Si Condition2
| Instructions3
| Aller à B
 
Instructions4
 
A:
Instructions5
 
B:

On a

Code :

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

1
2
3
4
5
6
7
8
9
10
Si Condition1
| Instructions1
| Instructions5
Sinon Si Condition2
| Instructions2
| Instructions3
Sinon
| Instructions2
| Instructions4
| Instructions5

(Je ne sais pas si on peut trouver un problème plus simple)

Le problème dans ce code est la répétition d'instructions. On utilisera sans trop de problème une fonction Instructions2(); pour résoudre ce problème. Plutôt que de voir une répétition d'instructions, on peut voir une répétition de test de condition :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Si Condition1
| Instructions1
 
Si NON Condition1
| Instructions2
 
Si Condition2 et NON Condtion1
| Instructions3
 
Si NON Condition1 et NON Condition2
| Instructions4
 
Si NON Condition2
| Instructions5

qui est une construction mécanique, ou alors pour être plus concis :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Si Condition1
| Instructions1 
Sinon
|
| Instructions2
|
| Si Condition2
| | Instructions3
| Sinon
| | Instructions4
|
 
Si NON Condition 2
| Instructions5

Ce code peut aussi être fabriqué de manière mécanique, en utilisant tant bien que mal le schéma du if-else plus haut et en repoussant les "cas non gérés" en dehors de la boucle. Ici, on a effectivement une répétition de conditions, qu'on pourra rendre moins lourde en stockant les résultat des tests dans des variables.

On peut le faire, mais c'est tout à fait dommage d'y être obligé, d'autant que le C perdrait un aspect : celui d'être un macro-assembleur. On ne pourrait pas écrire en C des solutions aussi rapides qu'en assembleur, alors que cela ne concerne que des instructions courantes en assembleur. S'il est tout à fait possible qu'un code assembleur soit plus rapide qu'un code généré par un compilateur C, parce que le code assembleur utilise des optimisation avoid conditional jump à grands coup de SETcc, MOVcc, SBB, ADC ou encore utilise le parity flag ou autre spécificité du x86 c'est normal, mais que le C se fasse battre par un jeu d'instruction réduit, c'est un outrage ! Le goto permet de garder toute la puissance de l'assembleur. (Ce qui ne sert pas tous les jours, j'en conviens, mais peut servir, notement - et il y en a au moins deux ici - pour ceux qui développent des émulateurs)

Ces transformations mécaniques peuvent être en revanche, absolument pas algorithmique. L'usage des goto dans l'exemple ci-dessus peut servir pour une éxecution dont la séquence n'est pas si rare que cela. C'est un genre de code emmerdant quand on ne veut ni faire de fonction, ni faire plusieurs fois les même tests. On peut trouver des branchements à tentacule, justifiés algorithmiquement (quoiqu'en les démontrant on utilisera une des formes obtenues mécaniquement) et qui n'ont absolument aucun sens avec une série de if. Mais dans ces cas, l'algorithme est de toute façon pénible à suivre sans crayon à portée de main, et alors le bénéfice du goto n'est que logique au dépend de la lisibilité, et on ne le trouve alors pas avantageux.

[Tchetch]

Le débat du goto a commencé avec Edsger W. Dijkstra et son célèbre papier "Go To Statement Considered Harmful" (1968) et a passé par tous les états d'âmes avec des documents nommés " 'Go To Statement Considered Harmful' Considered Harmful" et " ' "Go To Statement Considered Harmful " Considered Harmful ' Considered Harmful " ... Enfin c'est un débat sans fin, mais la plus grosse contre-attaque vient de Donald E. Knuth qui publia "Structured Programming with go to Statements" (1974).

Donc moralité, goto peut très bien s'utiliser, mais il faut savoir le faire correctement et avec modération (lire "Go To Statement Considered Harmful:
A Retrospective" pour des exemples.)

À lire :
Structured Programming with go to Statements : http://portal.acm.org/citation.cfm?i...FTOKEN=6184618
Go To Statement Considered Harmful : http://www.acm.org/classics/oct95/
Go To Statement Considered Harmful: A Retrospective : http://david.tribble.com/text/goto.html
http://en.wikipedia.org/wiki/Structured_programming
http://en.wikipedia.org/wiki/GOTO
http://en.wikipedia.org/wiki/Go_To_S...idered_Harmful

[baila ami ba]

ben moi la question de goto me pose enormement de probleme...
d'ailleurs des le debut, on me disait de ne pas avoir l'habitude d'utiliser GOTO dans tes programmes (mon prof)
donc il reste a suggerer pourquoi donc on a mis GOTO a la disposition des programmeurs ? Meme si on reste ignorant a propos de l'utilité de ne pas en abuser...

[Emmanuel Delahaye]

ben moi la question de goto me pose enormement de probleme...
d'ailleurs des le debut, on me disait de ne pas avoir l'habitude d'utiliser GOTO dans tes programmes (mon prof)
donc il reste a suggerer pourquoi donc on a mis GOTO a la disposition des programmeurs ? Meme si on reste ignorant a propos de l'utilité de ne pas en abuser...

C'est pas très clair ce que tu dis, mais je crois que le position raisonnable est la suivante :

Le langage C est basé sur les principes de la programmation structurée : structure de code, structures de données.

Il est donc logique d'utiliser le langage algorithmique pour concevoir le code et donc d'utiliser les mots de ce langages qui sont :

Code :

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

1
2
3
4
5
6
7
 
IF (if)
IF ELSE (if else)
SELECT CASE (switch case)
REPEAT UNTIL (do while)
WHILE (while)
FOR (for)

Pas de goto là dedans... Pourquoi ? parce que les structures de codes rendent inutles l'usage du goto. En C, il a été ajouté 2 'goto' déguisés qui sont 'break' (vers le bas) et 'continue' (vers le haut). Personnellement, en 17 ans de métier, je n'ai jamais utilisé 'continue', respectant ainsi (sans le savoir) les conseils de Knuth : pas de goto en arrière (boucle).

Maintenant, le break, je l'utilise évidemment comme tout le monde dans les switch-case, mais aissi parfois pour sortir d'une boucle plus simplement.

Quand au goto, pendant longtemps, je l'ai totalement banni, sans doute traumatisé par des débuts difficile en BASIC véritable (le poilu, le tatoué :10 GOTO 10).

Il m'est arrivé d'utiliser goto dans des macros de traitements d'erreurs pour alléger le code, en veillant bien à ce que les ressources soient bien libérées. Je n'aime pas trop ça et j'évite au maximum. Principal problème, ça rompt l'harmonie apportée par la structuration et ça rend le code difficilement découpable pour en utiliser des parties ou en faire des fonctions.

[Fabrice ROUXEL 1]

si on se decide d'oublier completmen cet instruction ben on risquerai de ne pas pouvoir faire certain programmes dans la mesure ou GOTO peu regler pa mal de probleme.

Goto ne régle pas des pb de conception, cette instruction qui traduit une déficience est le reflet d'un défaut de conception.

on peut s'en passer!

Debugger un code bourré de goto est laborieux. De plus la lecture du code est pénible, confuse.
Quand on commence à vouloir placer un GOTO, il vaut mieux repenser son algorithme.

[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 )

[bibilolo2]

Selon Peter Aitken et Bradley Jones:

Quand un programme exécute un branchement après une instruction goto, il ne garde aucune trace de l'emplacemet d'où il vient et l'ordre d'exécution va vite se compliquer. C'est ce que l'on appelle du code spaghetti.

[souviron34]

eh bien moi j'utilisais comme un forcené les GOTO en FORTRAN, car c'était la norme des programmes scientifiques, au début des années 80.

Les gros codes FORTRAN existants encore (librairie maths du CERN, modèles numériques) resteront tel quels, car personne ne les ré-écrira (de 20 à 30 ans de test opérationnel et +20 millions de lignes de code, ça se refait pas..).

Par contre, depuis 17 ans que je fait du C, et sur de très gros projets complexes (> 1 million de lignes de code) (au total plus de 2 millions de ligne de code), je n'ai JAMAIS utilisé un seul GOTO..

Effectivement le point central est la maintenance : il est extrémement difficile et long de relire et "formaliser" un code avec des sauts. Déjà c'est diffcile en Fortran avec les formats numérotés. Mais en plus avec les goto...

De plus, certaines normes pour certains types de projets (les projets de la NASA par exemple), en interdisent formellement l'usage.

Mais c'est principalement que c'est une autre manière de penser. Et bien sûr que l'assembleur fait des JMP. Mais ce pourquoi on a inventé des langages de programmation c'est justement pour pas être au niveau de la machine, mais au niveau conceptuel.....

[Thierry Chappuis]

Pas de goto là dedans... Pourquoi ? parce que les structures de codes rendent inutles l'usage du goto. En C, il a été ajouté 2 'goto' déguisés qui sont 'break' (vers le bas) et 'continue' (vers le haut). Personnellement, en 17 ans de métier, je n'ai jamais utilisé 'continue', respectant ainsi (sans le savoir) les conseils de Knuth : pas de goto en arrière (boucle).

J'utilise 'continue' parfois pour documenter une boucle dont le corps est vide:

Code :

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

1
2
3
4
for (i = 0; !isspace(s_buff[i]); ++i)
{
    continue;
}

équivalent à

Code :

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

1
2
3
4
for (i = 0; !isspace(s_buff[i]); ++i)
{
    /* Cette boucle ne fait rien! */
}

Thierry

[souviron34]

et par contre le continue je l'utilise pas mal, sur des grosses boucles, quand des conditions dynamiques sont réunies :

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
 
while ( 1 )
{
   for ( i = 0 : i < NDataSets ; i++ )
     {
          if ( NData[i] == 0 )
             continue ;
 
          .......
 
          if ( Settings_Have_Changed )
            {
               if ( Clear_Before_Next_Loop )
                    NData[i] = 0 ;
            }
     }
}

[paterson]

Pour moi , le GOTO existe en c , car il existai en assembleur , qui est bien pratique ( sans goto en assembleur pas de boucles possible )

Mais l'usage du goto est pas trés bon , car : GOTO : envoi a la ligne : donc les boucles qui as passer et tout ne se sont pas effacer du pointeur de pile , donc GOTO vous fait perdre de la ram ( pour un µc pas trop grave , mais comme moi qui programme en c des pic , sa deviens limite , car si tout les 30 ms il a 2 octet en plus utilisé dans la ram , en 30 s ma ram serai pleine ) vous vous avez peut étre 100 Mo de ram , moi 1024 max , mais bon le probléme que le programme plante existe toujours , car votre pc va pas faire la boucle que une fois ....

[Sanguko]

Il m'est arrivé d'utiliser goto dans des macros de traitements d'erreurs pour alléger le code, en veillant bien à ce que les ressources soient bien libérées. Je n'aime pas trop ça et j'évite au maximum. Principal problème, ça rompt l'harmonie apportée par la structuration et ça rend le code difficilement découpable pour en utiliser des parties ou en faire des fonctions.

Apres plusieurs années de tatonnement, j'en suis également arrivé à la conclusion que les goto pouvaient être utilisés pour le traitement de erreurs.
Je trouve ca plus lisible, voir plus sure que les if en cascade par exemple (ca ressemble en fait au mecanisme des exceptions). Je n'utilise pas de macro (je trouve ca mauvais pour la maintenance).

Emmanuel, je ne comprends pas tres bien ce que tu entends par "l'harmonie apportée par la structuration", ou "code difficilement découpable". Est ce que tu peux donner un exemple? Si tu connais également des articles sur le sujet, je suis preneur

[Emmanuel Delahaye]

Emmanuel, je ne comprends pas tres bien ce que tu entends par "l'harmonie apportée par la structuration", ou "code difficilement découpable". Est ce que tu peux donner un exemple?

Code harmonique :

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
27
28
29
30
31
32
33
34
35
36
37
 
#include <stdio.h>
#include <assert.h>
 
#define f_src "in.txt"
#define f_des "out.txt"
 
int main (void)
{
   FILE *fp_in = fopen (f_src, "r");
   if (fp_in != NULL)
   {
      FILE *fp_out = fopen (f_des, "w");
      if (fp_out != NULL)
      {
         int c;
         while ((c = fgetc (fp_in)) != EOF)
         {
            fputc (c, fp_out);
         }
         fclose (fp_out), fp_out = NULL;
      }
      else
      {
         perror (f_des);
      }
      assert (fp_out == NULL);
 
      fclose (fp_in), fp_in = NULL;
   }
   else
   {
      perror (f_src);
   }
   assert (fp_in == NULL);
   return 0;
}

Code cacophonique :

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
27
28
29
30
 
#include <stdio.h>
#include <assert.h>
 
#define f_src "in.txt"
#define f_des "out.txt"
 
int main (void)
{
   FILE *fp_in;
   FILE *fp_out;
   int c;
 
   if ((fp_in = fopen (f_src, "r")) == NULL)
      goto end;
 
   if ((fp_out = fopen (f_des, "w")) == NULL)
      goto end;
 
   while ((c = fgetc (fp_in)) != EOF)
      fputc (c, fp_out);
 
   fclose (fp_in), fp_in = NULL;
   fclose (fp_out), fp_out = NULL;
 end:;
 
   assert (fp_in == NULL);
   assert (fp_out == NULL);
   return 0;
}

Super compact et tout. Très C-geek.

Bug ! Si le 2ème fichier échoue à l'ouverture : le premier n'est pas fermé.

Ici, c'est sans conséquences, mais dans un serveur, ou autre 24/7, ca peut tuer assez rapidement...

[nemo69500]

ca me fais rire quand les gens dise "j'utilise pas de goto" parce que ces meme personne viennent utiliser des case avec les switch , des default ... et tous ceci sont des goto , enfin bon , le goto fais partis du c , il se compile avec gcc donc moi perso , si il est pas utiliser n importe comment je trouce ca correct

[Thierry Chappuis]

ca me fais rire quand les gens dise "j'utilise pas de goto" parce que ces meme personne viennent utiliser des case avec les switch , des default ... et tous ceci sont des goto , enfin bon , le goto fais partis du c , il se compile avec gcc donc moi perso , si il est pas utiliser n importe comment je trouce ca correct

Une structure switch/case/default est certes une sorte de goto déguisé, mais qui s'inscit parfaitement dans un contexte de programmation structurée. On peut toujours remplacer ce type de structure par quelque chose du style:

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
if (condition)
{
    /* ... */
}
else if (condition)
{ 
    /* ... */
}
else if (condition)
{
    /* ... */
}
else /* default */
{
    /* ... */
}

Personnellement, je trouve switch/case acceptable, lisible et ça ne donne pas lieu à du code spaghetti.

Thierry

[Emmanuel Delahaye]

Personnellement, je trouve switch/case acceptable, lisible et ça ne donne pas lieu à du code spaghetti.

Hey bro', ya sh'd try the Duff's Device...