for(;;) ou while(true) ?

Garulfo, ne te pose pas des œillères pour appuyer ton point de vue... On se place évidemment dans un cadre où il y a plusieurs points de sorties et on compare la solution avec break et la solution avec variable d'arrêt explicite, bien sûr que dans cet exemple ni l'un ni l'autre ne sont nécessaire !

L'idée était plutôt :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

while(1) { # code avec points de sortie if ( not debat_avancé() ) { break; } # code avec points de sortie }

---

contre

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

bool continue = true; while( continue ) { # code avec points de sortie donc {{{{ if( not debat_avancé() ) { continue = false; } else { # code avec points de sortie } #}}}} }

---

Je te laisse juger lequel est plus lisible.

--
Jedaï

et je driais même plus ;)

Code:

---

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

bool continue = true; while( continue ) { /* Some code */ if( not debat_avancé() ) { continue = false; } else { /* Some code */ if( not debat_avancé() ) { continue = false; } else { /* Some code */ etc etc etc } } }

---

Citation:

---

Envoyé par Jedai

Garulfo, ne te pose pas des œillères pour appuyer ton point de vue... [...]

Je te laisse juger lequel est plus lisible.

--
Jedaï

---

Mais tu ne donnes rien.
Donnes un cas avec du code (et pas des ...) et on verra si on ne peut vraiment pas faire un code lisible et propre. Admet que tu avais mal écrit ta transformation. Dans le cas très précis (et non significatif) ci dessus, le code avec variable n'était pas pire.

Je suppose cependant comme je disais à Souviron, que ça ne changera rien à votre avis. Et ce sera justifié. Tout exemple fourni ici ne saura être significatif. Je dis simplement, que le nombre de « break » est associé au nombre de modification des variables de la boucle de contrôle.. si tu fais du code où tu lances des breaks un peu partout ce n'est pas plus lisible qu'avec de multiple affectation de variables de contrôles. Si tu n'as que très peu de break tu auras peu d'affectation de variable de contrôle. Dans ton exemple, on ne peut pas dire que le premier est plus lisible, on ne sait pas ce qu'il y a dedans. Faire des breaks par succession de if est pire je pense.

Je continue à penser que ce n'est qu'une fainéantise de la part du programmeur et, plus souvent, une fainéantise de la part du concepteur qui mène souvent (pas tout le temps) à des conceptions bancales.

Citation:

---

Envoyé par souviron34

et je driais même plus ;)

Code:

---

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

bool continue = true; while( continue ) { /* Some code */ if( not debat_avancé() ) { continue = false; } else { /* Some code */ if( not debat_avancé() ) { continue = false; } else { /* Some code */ etc etc etc } } }

---

---

Toujours sémantiquement équivalent à

Code:

---

1 2 3 4 5 6 7

while( not debat_avancé() ) { /* Some code */ etc etc etc }

---

Si vous écrivez mal vos boucles forcément, il peut être mieux de mettre un while(1). Mais je suis convaincu que ce n'est pas un manque de compétence... juste un peu de fainéantise et d'effort. Et je suis aussi convaincu qu'on ne perdrait pas en lisibilité.

Souviron n'est du pas d'accord avec ce que je dis ? à savoir que si tu me donnes un exemple qui tient sur le forum et que je te fournis un code propre et lisible, tu me diras juste que ce n'est pas significatif ? C'est d'ailleurs un peu l'argument de Jedaï dans son poste: un vrai exemple est plus complexe.

Citation:

---

Envoyé par Garulfo

Toujours sémantiquement équivalent à

Code:

---

1 2 3 4 5 6 7

while( not debat_avancé() ) { /* Some code */ etc etc etc }

---

---

Non, dans un langage impératif les deux versions ne sont pas équivalentes, car le code peut modifier le résultat de "debat_avancé()" d'un if au suivant...

Citation:

---

Si vous écrivez mal vos boucles forcément, il peut être mieux de mettre un while(1). Mais je suis convaincu que ce n'est pas un manque de compétence... juste un peu de fainéantise et d'effort.

---

La conclusion est confuse, nous accuse-tu de manque de compétence et de fainéantise ou d'effort (sic) (il manque un mot, ou il faut revoir la structure de la phrase).

--
Jedaï

Citation:

---

Envoyé par Jedai

Non, dans un langage impératif les deux versions ne sont pas équivalentes, car le code peut modifier le résultat de "debat_avancé()" d'un if au suivant...

La conclusion est confuse, nous accuse-tu de manque de compétence et de fainéantise ou d'effort (sic) (il manque un mot, ou il faut revoir la structure de la phrase).

--
Jedaï

---

Mais on ne sait pas ce qui se passe dans cette version de debat_avance c'est pour ça que je dis que c'est non significatif. Je rappelle qu'il est établi que les erreurs de programmations ont surtout pour origine: les fuites mémoires et les effets de bords (études de Boehm pour la mise au point de la méthode Cocomo). Mettre un effet de bord dans un prédicat n'est pas une bonne idée conceptuelle. Donc on supposons que s'eut été le cas, il faudrait essayer de changer ça.

Et je ne vous accuse de rien du tout de particulier. J'accuse en général les développeurs de fainéantise oui. Mais pas vous en particulier. Ce n'est pas une nouveauté que les erreurs sont souvent dûs à une architecture défaillante dû à un manque d'effort. Ça pourrait aussi parfois s'appliquer à moi je suppose. Il ne faut pas prendre les discussions personnels Jedaï. Je ne t'accuse pas non plus de me prendre pour un imbécile, malgré le coup des œillères ;) Tu n'avais certainement pas dit ça avec une volonté de me diminuer n'est ce pas ?

Citation:

---

Envoyé par Garulfo

Je ne t'accuse pas non plus de me prendre pour un imbécile, malgré le coup des œillères ;) Tu n'avais certainement pas dit ça avec une volonté de me diminuer n'est ce pas ?

---

Non, je te trouve juste un peu borné sur ce point par rapport à d'habitude. Personnellement, les boucles infinies ne me choquent pas du tout, et bien qu'on puisse toujours les remplacer par des boucles non-infinies, je préfère souvent les garder telle quelle parce que je les trouve très lisibles.
Mais je suppose qu'à ce point on s'est ramené à une discussion sur le style et que nous pouvons aussi bien dire que les goûts et les couleurs ne se discutent pas... 8-)

--
Jedaï

Citation:

---

Envoyé par Jedai

Non, je te trouve juste un peu borné sur ce point par rapport à d'habitude. Personnellement, les boucles infinies ne me choquent pas du tout, et bien qu'on puisse toujours les remplacer par des boucles non-infinies, je préfère souvent les garder telle quelle parce que je les trouve très lisibles.
Mais je suppose qu'à ce point on s'est ramené à une discussion sur le style et que nous pouvons aussi bien dire que les goûts et les couleurs ne se discutent pas... 8-)

--
Jedaï

---

Disons que je pourrais être plus modéré comme ceci:

En règle général, les boucles infinies n'ont pas lieu d'exister. Tout comme le goto ce sont des facilités de programmation qui sont principalement dues à un manque d'effort de conception. Les cas utilisant des boucles infinis devraient être retravaillées pour les faire disparaître au profit de conditions et prédicats clairement énoncés. Il existe des cas, rares cependant, dans lesquelles une boucle infinie ne peut être supprimés qu'aux prix d'une illisibilité importante dans le code. Ceci ne survient que dans les cas où la conception devient arbitrairement complexe en conservant un paradigme de programmation structurée. C'est une situation complètement analogue à ce qui survient avec un goto: ils sont à proscrire en règle général mais peuvent, dans certains cas rares être nécessaire à une meilleure lisibilité. Malgré ces considérations, aucun débutant ne devrait utiliser ni des goto ni des boucles infinies. C'est, en effet, la prémisse de mauvaises habitudes et d'une fainéantise intellectuelle nocive dans les futures conceptions de projets complexes.

J'appuie mon raisonnement sur le fait que plus tu mets de break moins tu contrôles en général la logique de ton code. Un break est l'équivalent d'un goto. Les remarques de Hoare sont donc toujours valides. Lorsque le nombre de break est important, la conception devrait être retravaillée; lorsque le nombre est faible, la conversion de la boucle sera relativement simple. Certes cela suppose qu'il n'y a pas trop d'effet de bord dans les prédicats, mais une bonne conception devrait les limiter au maximum, car comme Boehm l'a démontré, les erreurs de programmations ont comme source principal ces derniers (et la gestion implicite de mémoire).

Je n'ai pas juste balancé un avis sans réflexion... j'y ai souvent réfléchi et j'en ai souvent discuté. Mais je peux me tromper... c'est vrai. Pour l'instant je n'ai rien vu qui me l'indique, y compris dans des domaines où la programmation par effet de bords est nécessaire (comme la programmation fortement parallèle).

Citation:

---

Envoyé par Garulfo

En règle général, les boucles infinies n'ont pas lieu d'exister.

---

ca c'est nouveau.

Citation:

---

Envoyé par Garulfo

Tout comme le goto ce sont des facilités de programmation qui sont principalement dues à un manque d'effort de conception.

---

Je ne suis pas d'accord tu ne peux pas comparer les boucles infini avec le goto qui est a mon sens ne trés mauvaise "instruction"... ils n'ont pas du tout le meme but ni le meme fonctionnement.

Citation:

---

Envoyé par Garulfo

Les cas utilisant des boucles infinis devraient être retravaillées pour les faire disparaître au profit de conditions et prédicats clairement énoncés. Il existe des cas, rares cependant, dans lesquelles une boucle infinie ne peut être supprimés qu'aux prix d'une illisibilité importante dans le code. Ceci ne survient que dans les cas où la conception devient arbitrairement complexe en conservant un paradigme de programmation structurée.

---

Tu pourrais etre un peu plus explicite ? je suis convaincu qu'une boucle infini utilisé proprement est plus efficace parfois...

Citation:

---

Envoyé par Garulfo

C'est une situation complètement analogue à ce qui survient avec un goto: ils sont à proscrire en règle général mais peuvent, dans certains cas rares être nécessaire à une meilleure lisibilité.

---

tu y tiens a ton goto.

Citation:

---

Envoyé par Garulfo

Malgré ces considérations, aucun débutant ne devrait utiliser ni des goto ni des boucles infinies. C'est, en effet, la prémisse de mauvaises habitudes et d'une fainéantise intellectuelle nocive dans les futures conceptions de projets complexes.

---

je suis d'accord pour le goto mais pour ta gouverne le premier prof avec qui j'ai commencé a programmer me faisait toujours mettre mon prog dans une boucle infini. C'étais des prog sur pickit je m'en souviens encore.

Citation:

---

Envoyé par Garulfo

J'appuie mon raisonnement sur le fait que plus tu mets de break moins tu contrôles en général la logique de ton code.

---

mais pourquoi pensez vous qu'un while(1) a forcement 50 break ? Il peut trés bien n'en avoir qu'un et être utile qd meme.

Citation:

---

Envoyé par Garulfo

Un break est l'équivalent d'un goto.

---

FAUX FAUX et ARCHIFAUX je suis désolé mais tu vas un peu trop loin la


tout ca pour dire qu'une boucle infini bien utilisé n'a rien de choquant. Ceux qui n'ont pas envie de l'utiliser tant pis pour eux mais ne tennez pas pour règle d'or un choix arbitraire de votre part.

PS : et please arréter de comparer while(1) + break et goto parce qu'il n'ont aucun rapport l'un avec l'autre.

je remets un coup mon grain de sel ...

qeu pensez vous de ... ???

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

try { while (1){ if (...){ throw(debat_ne_progresse_plus_exception()); } } } catch (debat_ne_progresse_plus_exception d){ }

---

ou meme de

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

bool faire_quelquechose(){ if (...){ throw(debat_ne_progresse_plus_exception()); } } try { while (faire_quelquechose()){ } } catch (debat_ne_progresse_plus_exception d){ }

---

Citation:

---

Envoyé par nayah

[...]
Tu pourrais etre un peu plus explicite ? je suis convaincu qu'une boucle infini utilisé proprement est plus efficace parfois...
[...]
tu y tiens a ton goto.
[....]
je suis d'accord pour le goto mais pour ta gouverne le premier prof avec qui j'ai commencé a programmer me faisait toujours mettre mon prog dans une boucle infini. C'étais des prog sur pickit je m'en souviens encore.
[...]
mais pourquoi pensez vous qu'un while(1) a forcement 50 break ? Il peut trés bien n'en avoir qu'un et être utile qd meme.
[...]
FAUX FAUX et ARCHIFAUX je suis désolé mais tu vas un peu trop loin la
[...]
tout ca pour dire qu'une boucle infini bien utilisé n'a rien de choquant. Ceux qui n'ont pas envie de l'utiliser tant pis pour eux mais ne tennez pas pour règle d'or un choix arbitraire de votre part.
[...]
PS : et please arréter de comparer while(1) + break et goto parce qu'il n'ont aucun rapport l'un avec l'autre.

---

Je n'ai jamais parlé de performance.

Je n'ai jamais dit que boucle infini équivaut à multiple break: j'ai dit que s'il y a de multiple break alors il est aussi difficile à lire que de multiple affectation d'une variable de contrôle et que s'il n'en a pas beaucoup, il est a priori aisé de le transformer sans boucle infini tout en gardant la lisibilité.

Et un break est un goto : un bris de la programmation structurée effectué par un saut en dehors d'un block d'instruction. Ça peut ne pas te plaire mais c'est ainsi. Le switch/case en C est un très bon exemple justement de goto. Ton premier prof pouvait bien utiliser des break et pas des goto, je ne vois absolument pas le rapport. Si ton premier prof de programmation te faisait mettre toujours un while(1) je ne donne pas cher de ses compétences pédagogiques. Comme je le mentionnais, je pourrais comprendre qu'un développeur expérimenté pleinement capable de contrôler la logique de son programme y mettent des break et des while(1)... mais faire apprendre ça à des débutants est complètement stupide.

Le break est une forme de goto, tout comme le traitement des exceptions par try/catch ou comme la programmation par continuation. Je suis désolé que ça te déplaise mais c'est ainsi. Si l'exemple suivant, bien que très artificiel montre le rapport:

Code:

---

1 2 3 4 5 6 7 8 9

while(1) { if (condition) goto sortie_de_boucle; // break   traitement(); } sortie_de_boucle: suite() ;

---

alors quelques citations provenant d'un site:

Citation:

---

je vois pas pkoi vous vous prenez la tête avec le goto. en java y a pas de goto. point.

Citation:

---

In the JavaTM programming language, goto is a reserved word; the Java programming language does not have a goto statement. However there are alternative statements that you can use in the Java programming language in place of the goto statement.

---

c'est juste un mot reservé mais y a rien derrière.

---

Citation:

---

Le break aussi c'est bien aussi pour eviter des "return" multiples, ou en milieu d'iteration:

Code:

---

1 2 3 4 5 6 7 8

result = null boucle { if (condition) { result = valeur_courante break } }

---

return result

---

Citation:

---

Le break peut être utile aussi dans des boucles où la condition d'arrêt est au milieu de la boucle :

Code:

---

1 2 3 4 5

loop ... exit when (condition-is-true); ... end loop;

---

Vous allez me dire, ça se simule très bien, soit en dupliquant le code (beurk ! trappe à bugs, pourtant utilisée dans 80 % des cas), soit avec un joli booléen dans un while. Mais à mon avis, la solution de la boucle infinie rend le code moins complexe.

En C/C++, ça se lit très bien si on utilise les macros :

Code:

---

1 2	#define forever() for(;;) #define EXIT_WHEN(cond) if (cond) break

---

Ce qui donne :

Code:

---

1 2 3 4 5

forever() { ... EXIT_WHEN(condition-is-true); ... }

---

En Java, l'absence de macros oblige à utiliser explicitement le "break".

---

bon

juste on ne se convaincra pas, mais j'avoue être sceptique sur l'axiome énoncé par Garulfo sur l"'évitement d'une boucle infinie".

Et de plus, Garulfo, non les break et les goto ne sont pas équivalents.

• Un break est forcémernt DANS LE FLUX du programme, et brise la linéarité DE L'INSTRUCTION EN COURS (for, while, etc).
  
• Le goto est dans N'IMPORTE QUEL SENS par rapport au flux du programme, et brise la linéariteé DU PROGRAMME

C'est cette caractéristique qui rend le goto A EVITER ABSOLUMENT

Je me souviens de programmes FORTRAN du style :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

IPASS = 0 10 IF ( IPASS EQ 2 ) GOTO 30 I = 0 J = -1 FOR K = 0, K=10, K=K+1 L = L + 1 IF ( L EQ 4 ) GOTO 20 END FOR GOTO 30 20 WRITE ( 6, "Passage"); IPASS = IPASS + 1 GOTO 10 30 WRITE (6, "FINI !!!") .........

---

sans compter le goto assembleur qui peut sauter de routine..

Citation:

---

Envoyé par souviron34

• Un break est forcémernt DANS LE FLUX du programme, et brise la linéarité DE L'INSTRUCTION EN COURS (for, while, etc).
  
• Le goto est dans N'IMPORTE QUEL SENS par rapport au flux du programme, et brise la linéariteé DU PROGRAMME

---

+1

Citation:

---

Envoyé par souviron34

bon

juste on ne se convaincra pas, mais j'avoue être sceptique sur l'axiome énoncé par Garulfo sur l"'évitement d'une boucle infinie".

Et de plus, Garulfo, non les break et les goto ne sont pas équivalents.

• Un break est forcémernt DANS LE FLUX du programme, et brise la linéarité DE L'INSTRUCTION EN COURS (for, while, etc).
  
• Le goto est dans N'IMPORTE QUEL SENS par rapport au flux du programme, et brise la linéariteé DU PROGRAMME

---

+99999 99999 9999

Merci!!!! Je commencais a desesperer.

Citation:

---

Envoyé par souviron34

bon

juste on ne se convaincra pas, mais j'avoue être sceptique sur l'axiome énoncé par Garulfo sur l"'évitement d'une boucle infinie".

Et de plus, Garulfo, non les break et les goto ne sont pas équivalents.

• Un break est forcémernt DANS LE FLUX du programme, et brise la linéarité DE L'INSTRUCTION EN COURS (for, while, etc).
  
• Le goto est dans N'IMPORTE QUEL SENS par rapport au flux du programme, et brise la linéariteé DU PROGRAMME

[...]

---

Ils ne sont pas équivalent dans la pure sémantique, c'est vrai. Ce n'est pas ce que je voulais dire. Je voulais dire que les conséquences d'usage sont les mêmes. Un break est une forme de goto... C'est un saut qui brise la programmation structurée (plus que la linéarité).

Nayah et Smashy c'est cette dernière chose qui est l'important : ça brise la structure logique du programme. Si Hoare était contre les goto c'était principalement parce que c'était opposé au paradigme de la programmation structuré. Le goto comme le break allait à l'encontre de la logique de Hoare (c'est une logique, ce n'est pas une expression pour dire « le bon sens de Hoare »). En ce sens : le break et le goto sont équivalents ! Je parlais d'une équivalence de conséquence. Si ce n'était que le problème de sens, il suffirait d'imposer que le goto n'aille que dans un sens. Hors le problème n'est pas là: le while revient aussi en arrière. Le problème est qu'il est compliqué de suivre un programme qui utilise des sauts break ou goto, et pour Hoare ceci empêche la construction de programme basé sur une logique solide permettant d'établir un degré de sureté important (apport de preuve).

Donc je suis bien désolé, mais sur ce point, quoique tu en dises Souviron, ça ne change rien. Et je continue à dire haut et fort que JAMAIS on ne devrait enseigner à un étudiant débutant à faire des while(1) avant de lui apprendre à construire correctement ces boucles. Tu as eu un mauvais prof Nayah (qui pouvait être un très bon développeur cependant). Je suis déjà intervenu quelque part pour dire que un goto pouvait être bien utilisé, malgré ce qu'en dit Hoare. Mais c'est débile d'apprendre ça à un étudiant débutant. C'est la même chose pour les boucles infinis !

Je ne pense pas que se soit un mauvais prof... Il nous apprenais juste a nous en sortir afin que nous arrivions a programmer nos microcontroleurs après je continue quoi que tu en dise a penser que le break n'a vraiment rien a voir avec le goto car tu oublie quelque chose... Le goto est dangereux car il renvoi n'importe ou dans le programme alors que les instructions breauk et continue ne rélise que des sorties de boucle.

De meme je pense sincerement que les boucles infinis ont leur utilité (regarde l'architecture d'un OS et tu veras) et que se refuser a les utilisé pour les raisons que tu évoques n'a pour moi aucun sens. Je pense plutot que tu as pris une habitude (comme nous tous) et que tu tiens cette habitude comme vérité.

Citation:

---

Envoyé par nayah

JLe goto est dangereux car il renvoi n'importe ou dans le programme

---

Ce n'est pas vrai dans tous les langages; ne pas faire de généralisation hâtive non plus.

Citation:

---

Envoyé par nayah

[...]regarde l'architecture d'un OS et tu veras et que se refuser a les utilisé pour les raisons que tu évoques n'a pour moi aucun sens. Je pense plutot que tu as pris une habitude (comme nous tous) et que tu tiens cette habitude comme vérité.

---

Arrête ce genre de remarque ! J'ai probablement plus d'expérience que toi dans les OS et dans les micro-contrôleurs, mais je ne m'en suis pas vanté c'est tout.

Tu te trompes pour « l'habitude ». C'est le contraire. J'ai appris à programmer comme un cochon ça fait un peu plus de 20 ans quand j'étais gamin. Depuis j'ai appris la discipline et j'ai revu mon jugement sur bien des choses que je croyais acquises, notamment celle-ci.

Un prof qui t'apprend à faire des boucles infinis dans tes premiers programmes est un mauvais pédagogue ! J'insiste dessus. Il peut être excellent développeur maintenant, ça n'a pas forcément un rapport.

Et encore une fois quoique tu en dises, le goto et le break sont reliés dans leurs utilisations. Ils brisent tous les deux la programmation structuré et c'est ça qui est dangereux: quelque soit le « sens » du saut.

garulfo , que penses tu des exceptions ? (j entends "throw ...")