Discussion :

[koala01]

(snip)

C'est comme tout : il faut être raisonnable.

Si certains ici mettaient leur nez dans le noyau Linux...

Justement, le fait de mettre son nez dans le noyau linux devrait, au contraire, inciter les gens à coder de manière beaucoup plus stricte...

Le but des jalons posés par les différentes regles de codage est multiple:

Assurer la pérénité du code: un code écrit aujourd'hui, dans le cadre de la NASA pourrait n'être utilisé en conditions réelles que dans 20 ou 30 ans: dix avant meme que la sonde qui l'utilise ne se retrouve dans le nez d'une fusée et dix ou vingt avant que la sonde n'atteigne l'endroit qu'elle est supposée étudier... Et se retrouver au fond d'un coffre (ou sur une bande de sauvegarde quelconque) pendant tout ce temps...

Mais, dans vingt ou trente ans, le programmeur qui a écrit le code sera soit occupé sur un autre projet, soit pensionné, s'il n'a pas été viré et qu'il ne s'est pas fait renverser par une voiture...

Si, pour une raison ou une autre, il faut modifier ce code, il faut que celui qui aura à le modifier préfère apporter des changements au code existant au fait de le réécrire entièrement à sa main.

Pour atteindre cette pérénité du code, il faut que le type qui lit le code pour la première fois soit en mesure de déterminer précisément

• le but du code
• la logique qu'il est sensé suivre
• la manière dont la logique a été implémentée
• les dépendances éventuelles par rapport à d'autres modules/fonctions/valeurs
• d'autres choses auxquelles je n'ai peut etre pas pensé

De ce seul point de vue, et bien que je lui reconnaisse de tres grandes qualités, le noyau linux, qui n'a qu'une vingtaine d'années, ne peut pas vraiment se prévaloir d'une pérénité à toutes épreuves, avec ses deux versions principales et son nombre incroyable de sous versions (sans meme prendre en compte les bugfixes)...

Fatalement, essayer d'apporter un maximum de sécurité au niveau de l'allocation et de la libération des ressources: il est préférable d'éviter que le système ne plante apres cinq ans de "navigation" alors qu'il faudra dix ou quinze années supplémentaires pour atteindre le but

Assurer la sécurité des données elles-mêmes: l'espace est un millieu hostile, et certains rayonnements ou champs magnétiques sont susceptible de modifier les données.

Il faut donc impérativement pouvoir etre en mesure de récupérer les données d'une manière ou d'une autre...

Assurer un minimum de sécurisation lors de l'utilisation meme des données: Du fait qu'on a conscience que les données risquent d'être corrompues, il semble logique de prévoir un moyen de vérifier si elles l'ont été ou non avant d'essayer de les utiliser... Quelle que puisse etre leur origine.

Il y a sans doute d'autres points génériques importants auxquels une application spaciale devra etre attentive, mais, sur base de ces quatre seuls points, qui seraient à la limite à appliquer meme dans la "programmation de tous les jours", il y a déjà largement de quoi édicter une grosse vingtaine de regles à appliquer

Maintenant, il reste toujours le sujet de la "rigidité" des regles: certaines sont impératives (obligations/interdictions), d'autres nécessitent une sérieuse justification si elles ne sont pas suivies, et d'autres enfin peuvent n'etre que des conseils d'ordre pratique

Mais c'est comme les lois: dans tous les pays on te dit "tu ne tueras point"... Mais tous les pays acceptent l'idée que tu tues le type qui fonce vers toi avec un poigngard dans la seule idée de te l'enfoncer dans le coeur (la légitime défence, comme on dit )

[Normand_Martel]

J'essaie autant que possible d'éviter les GOTO's mais je ne suis pas intégriste à ce point. Il m'arrive à l'occasion d'intégrer un GOTO RAREMENT deux.

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

Vous l'aurez deviné.... j'utilise beaucoup les while!!

[jack_x4]

GOTO = porter préjudice à leur fièreté de programmeur, rien de plus.

Si 'on' a inventé des while et des for, c'est pas pour faire machine en arrière pour utiliser un GOTO, tu vois ce que je veux dire ?

C'est une question de principe pour ceux qui code.

PAR CONTRE: si tu fait un programme qui est destiné a être envoyé sur un microcontroleur, et bien avec un GOTO tu peux faire déborder ton stack pointeur car le saut d'adresse peut être trop grand ! donc ton programme bug

Je vois rien d'autre

[Jean-Marc.Bourguet]

PAR CONTRE: si tu fait un programme qui est destiné a être envoyé sur un microcontroleur, et bien avec un GOTO tu peux faire déborder ton stack pointeur car le saut d'adresse peut être trop grand ! donc ton programme bug

?

[gdelhomme]

il me semble qu'à l'origine il n'y a que le goto,

que le call de la programation structurée est venu plus tard et avec lui les fameux problèmes de pile

et que le goto présente sur le while et le for l'avantage de la vitesse et l'absence d'utilisation de la pile

si je devais faire un programme ou je ne souhaite aucune interception de mes adresse de sous routine par la pile, je le ferais completement en goto,

bien agencés

maintenant parlons au niveau symbolique

je trouve que la programation struturée ça fait très petit bourgeois, du genre, vas y l'alu, fait ta routine et reviens pour le jt de 20 heure, et avant de partir met tes chausson dans la pile tu les recupéreras en rentrant

bon ok, pour les gros programmes ou il y a toujours des problèmes avec le parquet...

mais le goto, lui c'est la liberté
je pars et je reviens si nos chemin se croisent encore

bon d'accord ça met le bordel pour les impots,
mais que voulez vous nos vies ressemble à nos programmes,
si nous mettons que des routines dans nos programmes
nous aurons peut être tendance à ne mettre que des routines
...dans nos vies

[kromartien]

Goto : la seule utilisation raisonnable que je lui vois est un saut d'une procédure à une autre dans un code assembleur.

L'employer dans un algorithme itératif me semble réellement être une solution héritée d'une pratique de la programmation ancienne qui ne se veut pas réellement une transcription algorithmique.

Pour moi ça ressemble juste à une "spécificité" de microcontrôleurs. Bien sûr les branchements conditionnels, c'est bien, mais ça veut dire quoi concrétement ?

Qui veut apprendre la programmation directement depuis l'assembleur ? Les structures conditions c'est utile non, on peut faire plein de choses avec, on se creuse moins la tête aussi, et c'est plus rapide.

Goto : outil archaïque. Pourquoi l'utiliser encore, les structures de contrôles des langages évolués se substituent de façon plus élégante et plus efficace, et surtout, plus universelle aux goto.

Dans tous les cas, je crois bien qu'il est possible d'écrire n'importe quel programme sans Goto, qui est, une instruction héritée de l'assembleur (ancien), pourquoi dire encore les GOTO c'est bien ? Goto ça existe, mais en C ça fait plus rire qu'autre chose. Et bonjour la perte des avantages de la programmation structurée.

[millie]

Goto : la seule utilisation raisonnable que je lui vois est un saut d'une procédure à une autre.

Il n'est pas possible de sauter d'une fonction à une autre avec un goto. La seule solution pour ça est d'utiliser les longjmp/setjmp.

[Neitsa]

Ceci dit, le noyau linux n'est pas exempt de goto :

Code :

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

1
2
3
 
$ grep -R 'goto' /usr/src/linux | wc -l
46390

J'imagine qu'il doit y avoir quelques goto dans les commentaires mais tout de même... + de 46000...

[GnuVince]

À mon avis, le goto a sa place. Il faut savoir quand l'utiliser et pas revirer crack-pot, mais un goto bien placé peut certainement aider la lisibilité d'une fonction:

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
 
void foo()
{
  while (...) {
    for (...) {
      while (...) {
        if (vraiment gros probleme) {
          goto FIN;
        }
      }
    }
  }
FIN:
  bar();
}

Comme on peut pas donner de labels aux boucles en C (comme en Perl) ou spécifier la profondeur de break (comme dans Ruby ou Python), je crois qu'un goto est la façon la plus claire de quitter une boucle très profonde.

La seule chose importante à se rappeler est que les fonctionnalités d'un langage sont faites pour être utilisé. Je me rappelle dans les lectures de SICP, les deux professeurs disent à quel point SET! dans Scheme (l'assignation) est terrible. Pourtant les programmeurs en C s'en serve énormément et ne s'en font pas, malgré les risques et inconvénients. Pourquoi mettre SET! dans Scheme si c'est si terrible? Parce que ça rend une classe de problèmes beaucoup plus simple à résoudre.

[millie]

Ceci dit, le noyau linux n'est pas exempt de goto :

Code :

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

1
2
3
 
$ grep -R 'goto' /usr/src/linux | wc -l
46390

J'imagine qu'il doit y avoir quelques goto dans les commentaires mais tout de même... + de 46000...

C'est souvent utile dans le cas où l'on est en mode noyau (on a accès à tous) et que l'on commence à traiter des données sensibles (par exemple le buffer cache). Il se peut souvent qu'une interruption arrive (ou que l'on s'endorme volontairement en attente d'une donnée) et que l'on se retrouve dans un état incohérent au moment de la reprise, il est souvent nécessaire de recommencer le traitement (on met un simple goto).

Par exemple, le code de getblk (recupération d'un bloc dans le buffer cache) va ressembler à ç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
 
getblk(dev, blockno) {
  hashq = hash_list(dev, blockno);
  loop1:
 
    for(q = hashq->forw...) {
     if(q->stat& BUSY) {
       s=splx(1);
       sleep(q);
       //après l'endormissement, la liste des blocs a pu être changé, on doit recommencer à parcourir
       goto loop1; 
     } 
     ....
 
   }
}

Il y aurait d'autre manière de faire (sleep est une primitive qui permet de s'endormir sur un "événement" (par exemple l'arrivée du bloc du disque dur vers la RAM) puis d'être placé dans la liste des processus Runnable.



Un petit code pour montrer que goto, c'est très bien (attention, code pas portable, dépend de l'orientation de la pile) :

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
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
#include <stdio.h>
#include <stdlib.h>
 
#include <setjmp.h>
 
static jmp_buf buf;
 
void f(void);
 
int p(jmp_buf u) {
    return setjmp(u);
}
 
void h(void) {
    int k = 41;
    int e;
    if(e==0)
        f();
    else
        longjmp(buf, 4);
}
 
void f(void)
{
 int i;
 int j;
 void *k;
 if(*(&j+1) != 42)  goto _____;
        int ll;
        int lll = 0;
    goto _______;
    ________:
    j = ((int (*) (jmp_buf)) ((void*) (*(&i-ll - ((int) cos(0)))))) (buf);
    if(*(&i-1) != 0) goto ___;
 
            h();
            goto _____;
 
                _______:
                if(lll!=0) { ll=(int) (*(&k+2)); lll=ll; }
 
                if(ll==1)  goto ________;
                    if(ll%2==0)
                        ll = ll/2;
                    else
                        ll = 3*ll+1;
              goto _______;
        ___:
            if(j!=4)
                h();
 _____:
 fprintf(stderr, "Fin");
}
 
void g(void) {
 int j;
 int i;
 j = 42;
 int (*h) (jmp_buf) = p;
}
 
int main(void)
{
    g();
    f();
	return 0;
}

[Médinoc]

Ça vient de l'IOCCC ?

[millie]

Ça vient de l'IOCCC ?

Non non, je l'ai écrit tout à l'heure

(je voulais faire un truc crade avec des goto uniquement, et je me suis dis que ce serait "marrant" d'utiliser des astuces avec la pile (par exemple le fait que des parties de piles soit initialisés dans l'appel de g) et des longjpmp/setjmp)

[souviron34]

...
Un petit code pour montrer que goto, c'est très bien (attention, code pas portable, dépend de l'orientation de la pile) :

Code :

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

1
2
 
...

Et tu trouves ca lisible, toi ????

Quel est l'energumene qui a remis ce debat sur le tapis ??? On etait bien arrive a une conclusion, non ?? et le debat etait bien marque "resolu" ...

Comme dit precedemment et dans plusieurs autres threads, bien sur on peut faire de tout avec tout...

Mais pour l'ECRASANTE majorite des utilisateurs de ce forum, nous ne le repeterons jamais assez PAS DE GOTO EN C ...

[millie]

Et tu trouves ca lisible, toi ????

Non, c'est le but.

[GnuVince]

Et tu trouves ca lisible, toi ????

Quel est l'energumene qui a remis ce debat sur le tapis ??? On etait bien arrive a une conclusion, non ?? et le debat etait bien marque "resolu" ...

Comme dit precedemment et dans plusieurs autres threads, bien sur on peut faire de tout avec tout...

Mais pour l'ECRASANTE majorite des utilisateurs de ce forum, nous ne le repeterons jamais assez PAS DE GOTO EN C ...

On devrait éviter les assignations aussi?

[Emmanuel Delahaye]

On devrait éviter les assignations aussi?

J'ai du mal à saisir le rapport. Pas assez de neurones...

[koala01]

Mais pour l'ECRASANTE majorite des utilisateurs de ce forum, nous ne le repeterons jamais assez PAS DE GOTO EN C ...

A titre personnel, je généraliserais même en pas de goto dans n'importe quel langage qui fournit le moyen de s'en passer (structures de test et différentes formes de boucles en tête), même si cela risque de faire dévier le débat

[GnuVince]

J'ai du mal à saisir le rapport. Pas assez de neurones...

L'argument habituel pour ne jamais utiliser goto (remarquez que je ne dis pas de s'en servir tout le temps, mais certaines situations sont juste plus élégantes avec un petit goto) est que goto rend le code difficile à suivre. Les assignations, qui sont en grand nombre dans des langages impératifs tels que le C, changent l'état du programme. C'est comme une ligne dans le temps: avant la ligne, le programme était dans un état X, après la ligne, il est dans un état Y. Quand on a des dizaines, voire des centaines de variables dans un programme qui peuvent tous changer, il peut être difficile de savoir exactement ce qui se passe.

Je ne suis pas entrain de dire de retirer les assignations, mais suite à mon expérience avec des langages qui ne permettent pas d'assignations (ex: Erlang), certaines classes de bogues sont simplement impossibles.

Pensons maintenant à break et continue: on peut dire que ce sont des goto déguisés, mais je ne vois personne s'opposer à leur utilisation (les switch seraient assez lourds sans break, qu'en pensez vous?)

Je crois que de dire en termes absolus qu'il ne faut jamais utiliser goto est ridicule. Il faut analyser la situation et faire un choix. Si goto était si mauvais et que personne ne devrait jamais s'en servir, il ne serait pas dans C.

[kromartien]

Si goto était si mauvais et que personne ne devrait jamais s'en servir, il ne serait pas dans C.

Mon opinion à ce sujet est qu'il subsiste seulement pour ne pas contrarier les mauvaises habitudes des développeurs.

[koala01]

(snip)
Je crois que de dire en termes absolus qu'il ne faut jamais utiliser goto est ridicule. Il faut analyser la situation et faire un choix. Si goto était si mauvais et que personne ne devrait jamais s'en servir, il ne serait pas dans C.

Heu, oui, et non...

Il faut quand même rappeler que, avant l'avènement des langages de troisième génération, l'équivalent au goto était la norme

Il faut aussi rappeler que, à cette époque, la principale méthode d'algorithmie était... le flowchart, qui était particulièrement adaptée à l'assembleur ou au langage machine dans le sens où la seule représentation possible d'une boucle passait par... le fait de "renvoyer" vèrs une instruction particulière, et que celle d'un test "à choix multiple" passait par... une succession de test "vrai/faux".

Quand les langages impératif de troisième génération sont arrivés, on peut estimer que, s'ils ont pris la peine d'implémenter le goto, c'est *sans doute* parce que l'usage des boucles - incrémentales ou non - n'était simplement pas encore passé dans les mœurs...

On peut aussi estimer que, si les langages ultérieurs ont continué à implémenter le goto, c'est sans doute à cause d'un constat troublant:

Quelqu'un qui programme depuis 20 ou 30 ans, qui a pris des habitudes algorithmiques ou de codage particulières ne sera que peu enclin à envisager de changer ses habitudes sous prétexte, justement que "je ne vois pas pourquoi c'était valable il y a 20 ans mais ne le serait plus aujourd'hui"...

Mais depuis que l'on a abandonné l'utilisation des cartes perforées au profit du clavier, les langages ont évolués et les techniques de programmation aussi:

La grosse majorité des langages impératifs de troisième génération apparus depuis ce temps (comme cela, je laisse la porte ouverte pour le cas où il y en aurait un qui ne soit pas dans le cas ) fournissent des structures qui permettent *dans la grosse majorité des cas* de se passer du goto.

Dés lors, en dehors des cas particuliers où son utilisation fournit un réel avantage par rapport aux autres possibilités, il n'y a que peu de raison de sacrifier la "lisibilité" du code en l'utilisant