Discussion :

[koala01]

OK. Pour définir une machine à état. Regrouper les erreurs en C. Pourquoi pas.

Et encore, c'était juste pour dire que chacun voit midi à sa porte...

On peut bien sur arguer qu'un code sera, dans certaines condition plus rapide qu'un autre, que les tests et les boucles ne sont que tes "goto" déguisés (dans le sens ou ils seront tous traduit en sauts, conditionnels ou non)... du moins, c'est le point de vue de linus, semble-t-il, mais je reste d'avis que son point de vue ne s'applique *éventuellement* que dans des cas bien particuliers...

Si dans le bouquin il y a des "p = new ... ; if(p)" et des goto. L'auteur ne connait pas le C++. Sur le plan qualité de code C++ je serai plus que méfiant à l'égard de ce bouquin. Si maintenant c'est l'OP a traduit des malloc en new. OK. Soit. C'est une façon de faire ...en C.

On est bien tous d'accord là dessus...

Ceci dit, et bien que ce soit un autre débat, Bjarne Strouptroup lui-meme, dans la quatrième édition de son bouquin "le langage C" (version francaise) propose des boucles infinies sous la forme

Code :

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

1
2
3
4
for( ; ; )
{
 
}

A moins qu'on ne m'apporte un raisonnement probant pour prouver que cette manière de faire apporte plus d'avantages que d'inconvéniants (utilisations probable de break "dans tous les sens", entre autres) je continurai à préférer les boucles while() et do...while() avec des tests adaptés pour les boucles infinies ... ou pseudo infinies...

Le problème, ce n'est pas le goto. C'est de faire des bidouilles en C++ qui complexifient le code et qui sont à côté de la plaque -- le comportement par défaut du new post-98 est de lever une exception, et les règles qualité sérieuses poussent vers les abstractions RAII comme les vecteurs.

Là dessus, nous sommes bien d'accord

Ne te méprend pas sur mon intervention passée... je ne voulais que présenter un "autre point de vue" soutenu par quelqu'un qui, de prime abord, a plus réfléchi à toutes les implications que moi, sans juger le moins du monde de la qualité (bonne ou mauvaise) de son raisonnement

Entre temps, pour ceux que cela peut intéresser, j'ai remis la main sur l'archive de la liste de diffusion en question: on la trouve =>ICI<=

[Jean-Marc.Bourguet]

A ce sujet, je suis tombé cette semaine sur un article de Knuth (?) qui faisait le point sur les erreurs techniques de notre profession. Il y targuait le switch de rejeton du goto, et racontait que cela ne valait pas mieux.

Tu parles de http://www.cs.inf.ethz.ch/~wirth/Art...s_origFig.pdf? C'est de Wirth. Le switch dont il parlait était celui d'Algol 60 qui ne ressemble en rien au switch de C mais plutôt à l'assigned goto de Fortran. Il propose en remplacement le case de Pascal et indique que le switch de C n'est pas aussi bien (il le traite de batard entre les deux solutions -- ce que je trouve sévère -- le pb c'est la nécessité de break)

[Luc Hermitte]

Ne te méprend pas sur mon intervention passée... je ne voulais que présenter un "autre point de vue" soutenu par quelqu'un qui, ...

Je n'étais pas sûr que mes propos avaient été bie compris en fait

Tu parles de http://www.cs.inf.ethz.ch/~wirth/Art...s_origFig.pdf? C'est de Wirth

Oui. C'est ça. Au temps pour moi. Je trouvais aussi sévère son jugement au sujet du switch C juste à cause de sa dependance au break.

[Jean-Marc.Bourguet]

Oui. C'est ça. Au temps pour moi. Je trouvais aussi sévère son jugement au sujet du switch C juste à cause de sa dependance au break.

Je crois que le problème tel que perçu par Wirth est que la nécessité de break, comme d'autres choses d'ailleurs dont le Duff's device, est une indication que le concept modélisé est plus proche du switch d'Algol que du case de Pascal. Mais d'après ce que je vois, l'usage fait est plus proche du case de Pascal que du switch d'Algol.