Discussion :

[cameleon65]

jeroman, c'est effectivement peut-être plus rapide en utilisant un pointeur, mais c'est de l'adressage indirect au lieu de l'adressage immédiat et je ne sais pas si ça réduit les performances.
Faudrait trouver un traitement qui nécessite au moins deux boucles imbriquées qui fait autre chose que de parcourir un tableau...

millie, l'appel d'une fonction réduit les performances ce qui favorise le goto...
Supposons qu'au début de la fonction on fasse fopen() et qu'à la fin on fasse fclose() juste après les traitements A à D, il y aura donc duplication d'instructions.

[millie]

millie, l'appel d'une fonction réduit les performances ce qui favorise le goto...

Le temps gagné est totalement ridicule par rapport au temps d'exécution d'une fonction (un seul appel) qui parcours un tableau de taille 100*100*100.
Si on pars dans ton principe, il est préférable de ne jamais faire de fonction et de ne faire que du goto quand on peut, ce qui est carrément pas gérable.

A noter que la fonction pourrait être inliné c'est une fonction interne (mais je doute de l'interêt pour une fonction qui n'est appelé qu'une seule fois par appel de verifierDiable)

Supposons qu'au début de la fonction on fasse fopen() et qu'à la fin on fasse fclose() juste après les traitements A à D, il y aura donc duplication d'instructions.

Il suffit de mettre les inscrutions dans la fonction verifierDiable et non verifierDiableAux et de passer le flux comme argument dans la fonction Aux, je ne vois pas trop où est le problème en fait

[metagoto]

Que pensez vous du goto ?

J'en pense que du bien.
Il faut savoir par exemple que goto a été tout récemment introduit dans php 5.3. Avec quelques restrictions, d'accord. Mais quand même, c'est pas rien!

Bon, plus sérieusement, je pense que goto est très bien lorsqu'il n'est pas directement utilisé par un humain. Pour tout ce qui est générateur de state machine, parser et autres, c'est parfait. Par exemple Ragel

[koala01]

Que pensez vous du goto ?

J'en pense que du bien.
Il faut savoir par exemple que goto a été tout récemment introduit dans php 5.3. Avec quelques restrictions, d'accord. Mais quand même, c'est pas rien!

Bon, plus sérieusement, je pense que goto est très bien lorsqu'il n'est pas directement utilisé par un humain. Pour tout ce qui est générateur de state machine, parser et autres, c'est parfait. Par exemple Ragel

Je ne suis, pas d'accord avec toi...

Dans de nombreux cas, la simple adaptation d'une boucle ou d'un test peu remplacer très avantageusement le goto.

Juste après au hit parade des raisons qui pousseraient les gens à l'utiliser vient la gestion des ruptures (pour les parser, par exemple)...

Le choix de méthodes préliminaire ou de représnetation d'algorithme adaptées, telles que jackson associée à nassi-schneiderman permettent très facilement, malgré leur coté "petit dessin", de s'en passer très facilement, y compris s'il s'agit de parser les informations.

Reste le cas de la gestion d'exception, qui ne représente que maximum 5% des cas dans lesquels nous pourrions être tenté de l'utiliser.

Et encore:

Si le langage propose un système de gestion des exception, autant en profiter.

Si le langage ne propose pas un tel système, le seul fait d'abandonner l'idée que SESE est la seule manière correcte d'envisager les choses fournira bien souvent une réponse correcte

Au pire, il restera quelque cas tout à fait particuliers dans lesquels goto peut effectivement s'avérer intéressant, mais ce seront une très large minorité.

Goto fait partie, au même titre que la récurisvité par exemple, de ces possibilités qui peuvent s'avérer très utiles dans certains cas bien particuliers, mais qui peut s'avérer extrêmement néfastes si elles sont utilisées à mauvais escient, toute la difficulté résidant dans l'identifcation du cas où ce genre de possibilité s'avérera effectivement être le choix le moins mauvais.

Le problème est que, bien souvent, lorsque notre première idée nous donne l'impression que nous nous trouvons dans ce cas, il faut vraiment accepter de réfléchir un peu plus en profondeur pour se rendre compte que notre première idée était effectivement mauvaise

[metagoto]

Je ne suis, pas d'accord avec toi...

C'est un droit inaliénable

As-tu bien lu mon post précédent ? J'ai peut être mal exprimé le fait que je suis tout à fait OK pour que des générateurs de code utilisent goto. Mais uniquement des générateurs de codes. Un vrai développeur de chair et d'os doit s'en prémunir au maximum, parce que c'est insupportable à lire, à suivre (et à imprimer ?)

[Sve@r]

Il faut savoir par exemple que goto a été tout récemment introduit dans php 5.3. Avec quelques restrictions, d'accord. Mais quand même, c'est pas rien!

Il n'existe pas en shell ni en Python (et je ne connais pas le perl mais si je devais faire un pari, je dirais qu'il n'y est pas non plus) et ça aussi ce n'est pas rien...

[zul]

C'est HS mais depuis quand la récursivité c'est "mal" ? (à par qu'aucun compilo C n'est foutu d'appliquer les optimisations correctes dans le cas d'une fonction recursive terminale).

[gl]

C'est HS mais depuis quand la récursivité c'est "mal" ?

La récursivité n'est pas "mal" en soi. Mais l'usage irréfléchie de la récursivité (et particulièrement de la récursivité non terminal) n'est clairement pas une bonne idée.

[cameleon65]

Le temps gagné est totalement ridicule par rapport au temps d'exécution d'une fonction (un seul appel) qui parcours un tableau de taille 100*100*100.
Si on pars dans ton principe, il est préférable de ne jamais faire de fonction et de ne faire que du goto quand on peut, ce qui est carrément pas gérable.

Pour avoir de meilleures performances, oui.

A noter que la fonction pourrait être inliné c'est une fonction interne (mais je doute de l'interêt pour une fonction qui n'est appelé qu'une seule fois par appel de verifierDiable)

Dans le cas de inline, ça revient au même que d'utiliser un goto, non ?

Il suffit de mettre les inscrutions dans la fonction verifierDiable et non verifierDiableAux et de passer le flux comme argument dans la fonction Aux, je ne vois pas trop où est le problème en fait

Dans ta solution, il y aurait une fonction qui créée une variable FILE*, fait un fopen(), puis fait un fclose(). Ces trois actions ne sont pas effectuées pour la fontion courante, mais pour une autre fonction, ce qui contrevient à la perspective d'encapsuler les différents traitements dans des fonctions distinctes.

[millie]

Dans ta solution, il y aurait une fonction qui créée une variable FILE*, fait un fopen(), puis fait un fclose(). Ces trois actions ne sont pas effectuées pour la fontion courante, mais pour une autre fonction, ce qui contrevient à la perspective d'encapsuler les différents traitements dans des fonctions distinctes.

Tu pourrais donner ton code d'exemple avec le goto. Car je ne suis pas sûr de saisir

[cameleon65]

Voici le code avec la l'utilisation d'un fichier:

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
38
39
40
41
42
43
44
45
46
47
48
49
 
#define NOMBRE_ELEMENTS	10
 
//Le tableau contient des nombres entre -70000 et 70000.
int verifierDiable(char* nomFichier, int tableau[NOMBRE_ELEMENTS][NOMBRE_ELEMENTS][NOMBRE_ELEMENTS])
{
	FILE* fichier = fopen(nomFichier, "r");
 
	if (fichier)
	{
		int i;
		int j;
		int k;
 
		for (i = 0; i < NOMBRE_ELEMENTS; i ++)
		{
			for (j = 0; j < NOMBRE_ELEMENTS; j ++)
			{
				for (k = 0; k < NOMBRE_ELEMENTS; k ++)
				{
					fscanf(fichierConfiguration, "%i\n", &tableau[i][j][k]);
 
					if (tableau[i][j][k] == 666)
					{
						printf("Le Diable! Fuyons!\n");
 
						goto DEVIL;
					}
				}
			}
		}
 
		printf("Le diable n'y est pas. Nous restons.\n");
 
		DEVIL:
			traitementA();
			traitementB();
			traitementC();
			traitementD();
 
			fclose(fichier);
	}
	else
	{
		printf("Attention: echec de l'ouverture en lecture du fichier \"%s\".\n", nomFichier);
	}
 
	return tableau[0][0][0] + tableau[6][6][6];
}

Je n'ai pas considéré la valeur de retour de fscanf().

[souviron34]

eh bien pour ma part, dans ce cas, c'est une horreur absolue..

[Médinoc]

En effet, c'est le genre de choses qui devraient être décomposées en fonctions.

[koala01]

C'est HS mais depuis quand la récursivité c'est "mal" ? (à par qu'aucun compilo C n'est foutu d'appliquer les optimisations correctes dans le cas d'une fonction recursive terminale).

Je n'ai jamais dit que la récursivité c'est mal, j'ai dit que la récursivité doit être envisagée lorsqu'elle est absolument indispensable et évitée s'il est possible de s'en passer.

J'ai aussi dit que, utilisée à mauvais escient, elle pouvait s'avérer particulièrement néfaste, ne serait-ce que par le risque de stack-overflow qu'elle implique.

Les exemples qui viennent tout de suite en tête sont ceux qui apparaissent beaucoup trop régulièrement dans les cours lorsqu'ils tentent de l'expliquer:

Le calcul de la factorielle, par exemple, n'a aucune raison d'être effectué sur une base récursive, parce qu'il est tout aussi facile de le faire à l'aide d'une simple boucle.

Par contre, s'il s'agit de résoudre les tours de Hannoï par exemple, la récursivité est largement envisageable comme étant la moins mauvaise solution possible, le fait de tenter de les résoudre de manière itérative risquant de compliquer énormément le raisonnement.

De même, le parcours en profondeur d'un arbre sera beaucoup plus facile à implémenter sous sa forme récursive que sous sa forme itérative, et il est donc parfaitement normal de l'envisager.

A ce titre, goto et la récursivité mènent le même combat: avant de décider d'y recourir, il faut avoir la certitude que ce sera la solution la moins mauvaise, à défaut d'être la meilleure.

Dans une grosse majorité des cas, on peut, et il est préférable de s'en passer, mais, dans quelques cas particuliers et très minoritaires, leur utilisation s'avérera indispensable

[Jean-Marc.Bourguet]

Par contre, s'il s'agit de résoudre les tours de Hannoï par exemple, la récursivité est largement envisageable comme étant la moins mauvaise solution possible, le fait de tenter de les résoudre de manière itérative risquant de compliquer énormément le raisonnement.

Il y a une solution itérative simple (déplacer le plus petit de manière cyclique, un mouvement sur deux, l'autre mouvement est imposé par la situation).

[J_P_P]

Bonjour,

Le "goto" c'est très bien si on ne l'utilise qu'à bon escient !
Il est, à mon avis, parfaitement correct d'utiliser cette instruction décriée
dans le cas des traitements d'erreur où il est nécessaire de stopper l'exécution du programme sans autre forme de réflexion, le "goto" renvoie à la routine d'erreur qui termine le programme ou la fonction.
J'ai aussi vu des utilisations du "goto" (en COBOL) pour envoyer directement à la fin d'une procédure utilisée en "PERFORM".

Dans les autres cas il vaut mieux éviter le "goto" qui rend souvent le code plus difficile à lire. Quoique les "bardées" de "if" imbriqués ne soient pas plus faciles a suivre s'il y a (je l'ai déjà vu) plus de deux niveaux d'imbrication. Mais il s'agit là plus d'une mauvaise structuration du code...

Cordialement

[edfed]

je code en asm, j'ai pas encore implémenté tout dans ma lib, mais le goto n'est pas prévu du tout. pour la simple raison que le goto, il est souvent implicite.

remarquez donc que la boucle for est obligée de faire un test, puis un branchement conditionnel, donc, un goto conditionnel.

je dirait que l'utilisation du goto peut être cool si utilisé à l'intérieur d'une fonction, sans jamais en sortir.
si l'on doit faire un goto vers un truc en dehors de notre fonction, il faut alors passer un paramètre indiquant le goto à faire avant de sortir de la fonction, puis avec un petit bout de code, effectuer notre goto à l'intérieur d'une condition.

le goto est implicite dans tellement d'instructions C de base qu'il est inutile de les lister.

le goto pur, lui, c'est juste un ordre pour signaler qu'il faut changer de bout de code, un peut comme si l'on faisait de la gestion de multitache, des trucs de système, pas des trucs d'applications.

cela dit, personne n'interdit un codeur de créer un microsysteme dans une application, pour gérer des choses, et utiliser des gotos, en général un seul dans la fonction tache_exec(), et utiliser des gotos dans le code principal pour appeler périodiquement la fonction tache_exec(), sans se soucier du contexte, ce quyi revient en fait à une interruption, ce qui est un goto asynchrone, périodique ou non.

mais bon, il y a le call, c'est à dire appel de fonction, qui permet de faire encore mieux.

donc, le goto passe à la trappe. même en asm, car jmp semble plus approprié pour signifier l'action du goto.

et oui, on jumpe, on saute littéralement dans une autre partie de code. une action nette.

j'ai pris au hasard un code asm, et j'en ai isolé le nombre de JMP purs (goto).

j'ai trouvé une fonction avec 5 goto (jmp) à l'intérieur

et je vais en faire une petite analyse simple.

Code asm :

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
38
39
40
41
42
43
44
45
46
 
  proc MainDlg hdlg, msg, wparam, lparam
    push    ebx esi edi
    cmp     [msg], WM_INITDIALOG ;case WM init dialog
    je      .wminitdlg ;on fait donc ce qui est là bas.
    cmp     [msg], WM_COMMAND ;idem, autre case
    je      .wmcommand ;autre case, autre routine
    cmp     [msg], WM_CLOSE ;encore un case
    je      .wmclose;etc..
    xor     eax, eax ;retourner 0 car on à rien fait, eax, c'est le return ? du C
    jmp     .finish ;on a terminé les cases, donc, endcase
    .wminitdlg:;case 1
      invoke  capCreateCaptureWindow, _camtitle, WS_VISIBLE + WS_CHILD, 10, 10,\
                                        266, 252, [hdlg], 0
      mov     [hWebcam], eax
      jmp     .finish ;ho, on a encore fini notre bout de case
    .wmcommand:;case 2
      cmp     [wparam], BN_CLICKED shl 16 + ID_START
      je      .startbutton ;case2.1
      cmp     [wparam], BN_CLICKED shl 16 + ID_STOP
      je      .stopbutton ;case2.2
      cmp     [wparam], BN_CLICKED shl 16 + ID_CLICK
      je      .clickbutton ;case2.3
    .wmclose:
      invoke  SendMessage, [hWebcam], WM_CAP_DRIVER_DISCONNECT, _camtitle, 0
      invoke  EndDialog, [hdlg], 0
 
 
;on sort ici, notre endcase, endfor, endif, end_quelque_chose...
    .finish:
      pop     edi esi ebx ;petit bout d'out-it impossible à contourner, sinon crack!!!
      ret
 
    .startbutton: ;case2.3
      invoke  SendMessage,  [hWebcam], WM_CAP_DRIVER_CONNECT, [nDevice], 0
      invoke  SendMessage,  [hWebcam], WM_CAP_SET_SCALE, TRUE, 0
      invoke  SendMessage,  [hWebcam], WM_CAP_SET_PREVIEWRATE, [nFPS], 0
      invoke  SendMessage,  [hWebcam], WM_CAP_SET_PREVIEW, TRUE, 0
      jmp     .finish ;fini le case
    .stopbutton:;case2.2
      invoke  SendMessage, [hWebcam], WM_CAP_DRIVER_DISCONNECT, _camtitle, 0
      jmp     .finish ;etc...
    .clickbutton:;case2.1
      invoke  SendMessage, [hWebcam], WM_CAP_FILE_SAVEDIB, 0, _filename
      jmp     .finish;etc...
  endp

case1 ou case2
dans case2, il y a 3 sous cases.
et tous font partie de la même fonction, qui est mainDlg, la fonction de dialogue principale d'une application win32, donc, du code système pour faire simple.
ce type de code est généré par le compilo C, ou le codeur ASM, mais pas le codeur C.

tout ces goto vont au même endroit, l'étiquette .finish n'est qu'une adresse dans le code.
ce sont de simples raccourcis vers la sortie.
ils sont indispensables dans un code machine, car en théorie, le cpu ne voit qu'une ligne de code à la fois, pas 30 comme nos éditeurs de texte, et donc, il lui faut bien des indications pour lui montrer la sortie de la fonction.

en C, ces jmp sont invisibles, ils sont implicites.
par exemple, pour exécuter un simple if x=0 x++, le CPU à besoin d'un:

Code :

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

1
2
3
4
5
 
cmp [x],0   ;x est egal à 0?
jne LA       ;non, on saute LA
inc [x]       ;oui, alors on va incrémenter x, x++
LA:         ;on arrive LA si x est différent de 0, ou à la fin de notre x++

évidement, le if n'est pas traduit ainsi dans GCC, il en faut bien plus, pour mettre en forme toutes les données, et exploiter le résultat...

mais l'idée est là, le goto est conditionnel, et implicite.

si l'on ajoute une ou deux conditions de tests, on aura tout à gagner à faire un case.
et lors de chaque tests de case, il y aura lieu de sortir en cas de résultat positif.
le goto est encore une fois implicite.

je ne connais pas encore l'instruction case du C, je débute dans deux jours seulement.
mais en gros, lorsqu'un cas est rencontré, il est inutile de continuer les tests, il faut donc sortir du case. et donc, chaque cas possède son petit bout de code, terminé par un jmp .finish, c'est à dire un goto .FIN.

et en parlant de fin, le goto est utile en prog système, car doit surement être encodé directement en jmp (enfin, j'espère). ce qui explique qu'il ne faut pas l'utiliser dans le code C, car si vous voyez le résultat de la compilation d'une fonction C, mettre un JMP dedans, c'est du suicide. les initialisations sont nombreuses, et sortir ou entrer dans passer par ces initialisations est le danger évoqué sur le GOTO

le goto ne doit donc pas sortir d'une fonction.

évidement, ça peut fonctionner car par exemple, notre code ne fait rien de complexe et donc, notre goto n'a aucune influence sur le reste.

mais si on devient un vrai programmeur, qu'on fait la maintenance du code, on va vite s'apercevoir que les goto (jump forcés), sont vraiment inutiles, et obligent à frapper 40 fois plus de code pour corriger les problèmes d'init et out-it de fonctions.

[artefactman]

Le goto n'est pas dangereux s'il est utilisé ponctuellement et intelligemment. Utiliser un héritage de l'assembleur n'est pas un crime. Il faut cependant bien faire attention à ce qu'on fait avec un goto. De nombreux logiciels/bibliothèques bas niveau l'utilisent (noyau linux, GCC ABI c++).

Un exemple d'utilisation méritant la pendaison :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
funcA()
{
     goto Etiq;
}
 
funcB()
{
Etiq:
   // traitements
}

Un exemple d'utilité :

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
 
 
for ()
{
       while ()
       {
                 for()
                 {
                           if (resultat_trouvé)
                              goto End;
                 }
       }
}
 
End:
      // cool !

Maintenant, est-ce qu'un enchaînement de boucles est vraiment nécessaire ? On pourrait aussi mettre la condition d'arrêt dans toutes les boucles, ce qui peut allourdir la lisibilité du code.

Si on dit que goto réduit à néant un code structuré, qu'en est-il de break et continue ? Ce sont des sauts inconditionnels aussi... mais limités ! Alors goto n'est pas plus dangereux qu'un break ou un continue, seulement il faut savoir l'utiliser correctement pour éviter de déstructurer complètement son code.

[koala01]

Si on dit que goto réduit à néant un code structuré, qu'en est-il de break et continue ? Ce sont des sauts inconditionnels aussi... mais limités ! Alors goto n'est pas plus dangereux qu'un break ou un continue, seulement il faut savoir l'utiliser correctement pour éviter de déstructurer complètement son code.

A vrai dire, dans mon code perso, je n'utilise le break que dans une seule situation : entre deux cas d'un test à choix multiple (case d'un switch), et jamais de continue...

Il y a tout à fait moyen de s'en passer dans les autres cas, d'autant plus que le simple fait d'imbriquer trois boucles mériterait presque lui aussi la pendaison

J'ai énormément de mal à envisager une situation dans laquelle trois boucles seraient imbriquées dans laquelle le principe de la responsabilité unique serait malgré tout respecté, et j'ai déjà repris pas mal de code dans ce sens :

Si une fonction ne doit avoir qu'une seule boucle non imbriquée et qu'elle doit se contenter d'appele une autre fontion qui contiendra la boucle "réellement active", pour moi, cela mérite d'être fait.

Et si, pour sortir de cette boucle, un return s'avère utile dans le cas où une condition est remplie, on sait au moins exactement où l'on va se retrouver par la suite

[Obsidian]

et jamais de continue...

C'est dommage parce que continue a un avantage non-négligeable dans le cas de for : celui d'honorer dans tous les cas la post-condition (généralement l'incrémentation de la variable). L'autre solution consiste à faire un if qui englobe tout ce qui aurait suivi le continue. Les deux approches se valent.

J'ai énormément de mal à envisager une situation dans laquelle trois boucles seraient imbriquées dans laquelle le principe de la responsabilité unique serait malgré tout respecté, et j'ai déjà repris pas mal de code dans ce sens :

Ben, chaque fois que l'on a affaire à plusieurs dimensions :

Code C :

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

1
2
3
4
5
6
7
8
9
    int tab[10][10][10];
 
    int longueur;
    int largeur;
    int hauteur;
 
    for (hauteur =0;hauteur <10;hauteur++)
    for (largeur =0;largeur <10;largeur++)
    for (longueur=0;longueur<10;longueur++) tab[hauteur][largeur][longueur] = 0;

Si une fonction ne doit avoir qu'une seule boucle non imbriquée et qu'elle doit se contenter d'appele une autre fontion qui contiendra la boucle "réellement active", pour moi, cela mérite d'être fait.

'faut se méfier des grands principes énoncés en programmation. Généralement, ils permettent d'identifier un cas de figurer récurrent en informatique et de s'y pencher scientifiquement. Mais c'est aussi bien souvent une manière d'inhiber le libre arbitre du codeur. Tout ces principes ne sont pas forcément valables, et ils sont généralement trop jeunes pour qu'on en fasse des dogmes.

Dans le cas du principe de la responsabilité unique, bon nombre de gens soulèvent justement le problème de sa granularité ; jusqu'où faut-il pousser le vice ?

Et si, pour sortir de cette boucle, un return s'avère utile dans le cas où une condition est remplie, on sait au moins exactement où l'on va se retrouver par la suite

Même chose avec un break, un continue et une fin de boucle ordinaire. Reconnais que trois fonctions pour les boucles ci-dessus seraient de trop, surtout si on tient compte du fait qu'elles sont les composantes indissociables de l'espace qu'elles forment.