Discussion :

[ulukahio]

Bonjour à tous, je me trouve devant un problème, à savoir que partout où je vais on me dit: "bouuh n'utilise pas goto c'est illisible, c'est nul, et en plus c'est pas bien". Mais voilà, je me suis donc débrouillé sans jusqu'à maintenant, mais je pense que pour ce que je dois faire l'utilisation de goto rendrait les choses plus claires.

En effet, je récupère une base de données en C sachant que les champs vides ne sont pas dans la base de départ. Donc quand je ne détecte pas un champ, je dois sauter toute une partie de mon code (qui traite les champ qui ne sont pas la), pour aller vers le reste.

Pourquoi un goto ne serait pas indiqué dans ce cas la? Je veux bien faire des tests avec des indices et compagnie mais je pense qu'un goto serait nettement plus clair, même pour les relecteurs.
D'avance merci.

[argoet]

La regle : Pas de goto dans un programme

La valeur d'un programmeur est inversement proportionnel au nombre de goto que l'on trouve dans son code

Pour clarifier ton programme Utilise les sous programmes avec les commentaire qui vont bien

[ulukahio]

La regle : Pas de goto dans un programme

oui bon je veux bien la croire ta règle, mais tu me répètes un peu ce que j'ai dit en haut ("les gotos c'est pas bien")... J'aimerai juste savoir pourquoi... Et pourquoi alors a-t-on implémenté le goto si c'est complètement inutile, voire dangereux?
J'ai pas demandé ce que vous pensiez du goto, j'ai demandé pourquoi vous pensiez qu'il fallait/ne fallait pas l'utiliser.

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

[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 ;
            }
     }
}

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

[Caine]

L'utilisation de goto casse le principe même de programmation structurée.

Ca pose d'énormes problèmes en preuve algorithmique, de plus l'état du programme peut devenir indéterminé dans un contexte multi-thread.

De toute manière, pour utiliser goto, il faut des branchements, autant utiliser ceux-ci pour "piloter" les portions de code à exécuter.

Dans le cadre de boucle, il est aussi lisible et efficace d'utiliser des clauses break, continue, return.

Le goto est un héritage de l'assembleur, rappelons que le C est un macor-assembleur avant de se vouloir un langage de haut niveau.

[ulukahio]

L'utilisation de goto casse le principe même de programmation structurée.

Ca pose d'énormes problèmes en preuve algorithmique, de plus l'état du programme peut devenir indéterminé dans un contexte multi-thread.

De toute manière, pour utiliser goto, il faut des branchements, autant utiliser ceux-ci pour "piloter" les portions de code à exécuter.

Dans le cadre de boucle, il est aussi lisible et efficace d'utiliser des clauses break, continue, return.

Le goto est un héritage de l'assembleur, rappelons que le C est un macor-assembleur avant de se vouloir un langage de haut niveau.

Alors je vais répondre point par point, le problème de preuve ne me dérange pas outre mesure dans mon cas, je ne fais pas de multithreading, ce n'est pas dans une boucle, et justement ce que je fais dans mon programme est vraiment très proche de ce que je fais en assembleur, vu que je fais de l'acquisition en binaire, et donc que je me déplace d'octets en octets sur un fichier sans jamais utiliser rien de plus complexe qu'un for ou un if... (bon des fprintf ok mais ça va pas très loin).

[Caine]

Je te conseilles de faire une recherche sur le net sur le sujet.

J'avoue que ça fait trop longtemps que j'ai quitté les bancs de la FAC pour me souvenir des raisons exhaustives et exactes de ne pas utiliser GOTO.

Mais après tout teste avec goto, en debug etc... Je ne suis pas intégriste sur ce point, mais je me souviens juste qu'un programme perd le côté structuré avec goto.

On peut arrivé à une étiquette par oubli de branchement sur une sortie ou sur une autre étiquette.

Ceci peut être désastreux, immagines que tu arrives là où tu utilises un pointeur alors qu'il n'est pas initialisé.

Enfin, en programmation structurée, ça arrive aussi.

Si tu trouves un site bien fait parlant du problème, je suis intéressé.

Bon GOTO

[ulukahio]

Mais après tout teste avec goto, en debug etc... Je ne suis pas intégriste sur ce point, mais je me souviens juste qu'un programme perd le côté structuré avec goto.

Oui je vais tester, je verrai bien si c'est complètement aberrant (ce qui m'étonnerait fort ;-))

On peut arrivé à une étiquette par oubli de branchement sur une sortie ou sur une autre étiquette.

Je n'oublie jamais rien 8)

Ceci peut être désastreux, immagines que tu arrives là où tu utilises un pointeur alors qu'il n'est pas initialisé.

Je n'utilise même pas de pointeurs dans mon programme.

Si tu trouves un site bien fait parlant du problème, je suis intéressé.

Ok je vous tiens au courant. Merci beaucoup pour ta réponse, c'est très sympa, je vais tenter de rechercher.

[argoet]

La regle : Pas de goto dans un programme

oui bon je veux bien la croire ta règle, mais tu me répètes un peu ce que j'ai dit en haut ("les gotos c'est pas bien")... J'aimerai juste savoir pourquoi... Et pourquoi alors a-t-on implémenté le goto si c'est complètement inutile, voire dangereux?
J'ai pas demandé ce que vous pensiez du goto, j'ai demandé pourquoi vous pensiez qu'il fallait/ne fallait pas l'utiliser.

Le goto à été écrit à une époque ou les sous programmes , les boucles et autres instruction "structuré" n'existaient pas

Reprends l'un des premiers basic microsoft (Dans les années 80-81)
Pour boucler un dizaine de fois tu faisais :

Code :

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

1
2
3
4
5
10 I=0
20 I = I + 1
30 PRINT I
40 IF I < 10 Then GOTO 20 
50 END

Bon ben maintenant tu admettras que cette façon de faire n'est plus d'actualité (surtout avec le C)

CQFD

[gege2061]

Pour faire simple: je ne suis pas du tout d'accord avec toi argoet (et tout ceux qui pense la même chose que toi!):

Le goto à été écrit à une époque ou les sous programmes , les boucles et autres instruction "structuré" n'existaient pas

Dans ce cas pourquoi l'avoir repri dans des langages récents tel que le C# : surtout qu'il existe des langage sans goto.

Les goto rendent le code illisible lorsqu'il sont mal utilisé mais ce n'est pas une exception en C. Il ne sont pas plus dangereux que des appels à malloc mal construit.

Je n'est jamais eu à utilisé de goto dans mes codes en C mais ce n'est pas par peur de les utiliser mais parce que je n'en ai pas besoin. Il sont trés utiles pour sortir d'une multitude de boucle imbréqué.

[calogerogigante]

Moi, personnellement, les goto, je les utilise !!

Modérement, mais je les utilise quand même...

Parfois, c'est bien pratique pour faire des petits tests, et je n'ai aucune honte, ni aucun problème à les utiliser quand c'est nécessaire...

Exemple très fréquents dans mes programmes personnels :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
//-------------------------------------------------------------
int testouinon(void) // renvoit 1 si oui, renvoit 0 si non.
{
int ch;
 
testOUIouNON:
ch=getch();
switch (ch) {
            case 'o': return 1;
            case 'n': return 0;
             default: goto testOUIouNON;
            }
}
//-------------------------------------------------------------

Ca n'a jamais planté, ni ralentit mon application...

FAUT JUSTE VEILLER A NE PAS TROP MULTIPLIER LEUR USAGE, POUR EVITER QUE TON CODE NE DEVIENNE ILLISIBLE...

[Ti-R]

C'est dangereux et cela ne sert à rien

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
//------------------------------------------------------------- 
int testouinon(void) // renvoit 1 si oui, renvoit 0 si non. 
{ 
            int ch; 
            while(1)
            {
                        ch=getch(); 
                        switch (ch)
                        { 
                                    case 'o': return 1; 
                                    case 'n': return 0; 
                        } 
            }
} 
//-------------------------------------------------------------

[calogerogigante]

Je vois pas ce que cela a de dangereux...

D'accord avec ton code !!
Mais je trouve quand même le mien bien plus lisible avec ce petit label, et ce petit goto...

;-) ;-) ;-) ;-) ;-)

[DavG]

La regle : Pas de goto dans un programme

Moi je dis : pas de goto pour ceux qui n'ont pas encore compris les principes du C .. par contre bien utilisé ça peut s'avérer utile comme par exemple dans un code très long pour rejoindre facilement un point de sortie en erreur dans la même fonction, mais bon, faut savoir s'en servir

La valeur d'un programmeur est inversement proportionnel au nombre de goto que l'on trouve dans son code

Ça, c'est ce que disent ceux qui ne comprennent pas l'interêt des goto

Pour clarifier ton programme Utilise les sous programmes avec les commentaire qui vont bien

Tu veux dire "sous-routines"?? Parfois tu ne veux pas appeler une sous-routine, surtout que tu ne peux pas toujours compiler inline et qu'une sous-routine va prendre plus de temps qu'un simple "goto error" !