for(;;) ou while(true) ?

Citation:

---

Envoyé par diva_69

OK merci des réponses :-)
Donc d'après toi "souviron34" au niveau du compilateur c'est la même chose et aucun n'est plus "optimisé" ?

---

diva_69,

Les développeurs inexpérimentés (on est tous passé par là...) se soucient trop d'optimisation. Si tu fais un traitement dans ta boucle, alors le temps passé à simplement exécuter le code qui gère la boucle sera négligeable. Et si tu ne fais pas de traitement, alors pas la peine de le rendre rapide!

Pour le début, laisse le compilateur décider à ce niveau de détails ce qui est optimal, et concentre-toi sur les choix d'algorithmes, de structures, etc.

Bon courage,

Carl

Citation:

---

Envoyé par Mat.M

Je veux bien mais c'est prendre certaines extrêmités; un chenillard c'est un chenillard et c'est sa seule fonction je regrette.
Un programme informatique c'est sensé effectuer plusieurs actions différentes, sauvegarder lire des données...bref il faut que l'utilisateur puisse interagir avec.
Imagines-tu dans un logiciel de compta ou bancaire mettre une boucle infinie ?

---

je ne t'ai donné qu'un exemple que les professeurs donnent a leurs élèves pour leurs montrer linteret des boucles infini... Elles permettent de creer un programme qui par exemple ne s'arrete que si il rencontrent une erreur et tourne le reste du temps et ces programme la sont nombreux.

Citation:

---

Envoyé par nayah

je ne t'ai donné qu'un exemple que les professeurs donnent a leurs élèves pour leurs montrer linteret des boucles infini... Elles permettent de creer un programme qui par exemple ne s'arrete que si il rencontrent une erreur et tourne le reste du temps et ces programme la sont nombreux.

---

Ce sont des mauvais profs dans ce cas.
Si un programme ne s'arrête que s'ils rencontrent des erreurs, il devrait essayer de gérer ça proprement et non mettre un while(1). Aucun programme n'est prévu ne jamais s'arrêter. Il y a toujours au moins une raison de terminer : on éteint le système.

Entre profs, nous nous sommes entendus que c'était une mauvaise idée d'apprendre ça aux étudiants car c'est un principe de fainéantise.

Maintenant que ça apparaisse dans des programmes n'est certainement pas une justification que ce soit une bonne chose. Je dirais que si les développeurs étaient effectivement excellents, ce serait probablement bien fait (l'utilisation d'une boucle infinie) et que ce ne serait pas grave. Mais c'est un peu présomptueux de croire que les développeurs sont tous bons. En général, on est mieux de supposer qu'ils sont à même de faire des erreurs.

Citation:

---

Envoyé par Garulfo

Maintenant que ça apparaisse dans des programmes n'est certainement pas une justification que ce soit une bonne chose. Je dirais que si les développeurs étaient effectivement excellents, ce serait probablement bien fait (l'utilisation d'une boucle infinie) et que ce ne serait pas grave. Mais c'est un peu présomptueux de croire que les développeurs sont tous bons. En général, on est mieux de supposer qu'ils sont à même de faire des erreurs.

---

Et alors ? Avec les systèmes de remplacement que tu proposes, il y a exactement les mêmes risques d'erreur : oublier un "break" ou oublier de changer l'état d'une variable sont aussi probables l'un que l'autre...

Je ne comprend pas bien cet entêtement contre une construction tout à fait légitime et propre... C'est une perversion du structuralisme de s'interdire toute instruction de contrôle de boucle. Autant je ne cautionne pas les "goto" sauf si on sait vraiment ce qu'on fait, autant "break" est une instruction bénigne.

--
Jedaï

la je dois dire que je soutiens totalement Jedai...

Citation:

---

Envoyé par Garulfo

Ce sont des mauvais profs dans ce cas.
Si un programme ne s'arrête que s'ils rencontrent des erreurs, il devrait essayer de gérer ça proprement et non mettre un while(1). Aucun programme n'est prévu ne jamais s'arrêter. Il y a toujours au moins une raison de terminer : on éteint le système.
Entre profs, nous nous sommes entendus que c'était une mauvaise idée d'apprendre ça aux étudiants car c'est un principe de fainéantise.

Maintenant que ça apparaisse dans des programmes n'est certainement pas une justification que ce soit une bonne chose. Je dirais que si les développeurs étaient effectivement excellents, ce serait probablement bien fait (l'utilisation d'une boucle infinie) et que ce ne serait pas grave. Mais c'est un peu présomptueux de croire que les développeurs sont tous bons. En général, on est mieux de supposer qu'ils sont à même de faire des erreurs.

---

Je résume ce que tu écris la :
- si le développeur est bon alors l'utilisation de la boucle infini est bonne et tout a fait autorisé.
- si le développeur n'est pas excellent et qu'il utilise une boucle infinie alors il s'agit d'une erreur.

si tu est vraiment prof et que tu applique deux corrections différentes a tes élèves en fonction de leur niveau tel que tu le décris je plains tes élèves.

Citation:

---

Envoyé par Jedai

Et alors ? Avec les systèmes de remplacement que tu proposes, il y a exactement les mêmes risques d'erreur : oublier un "break" ou oublier de changer l'état d'une variable sont aussi probables l'un que l'autre...

Je ne comprend pas bien cet entêtement contre une construction tout à fait légitime et propre... C'est une perversion du structuralisme de s'interdire toute instruction de contrôle de boucle. Autant je ne cautionne pas les "goto" sauf si on sait vraiment ce qu'on fait, autant "break" est une instruction bénigne.

--
Jedaï

---

L'utilisation d'une variable d'état (par opposition à l'usage d'instructions break) permet garantir que la boucle possède un seul point de sortie. C'est un des principes fondamentaux de la programmation structurée: un bloc doit posséder un seul point d'entrée et un seul point de sortie.

C'est évident qu'on touche ici à des questions d'ordre stylistiques et que les goûts et les couleurs... Mais je suis convaincu que multiplier les points de sorties par un usage abusif de break ou continue nuit à la lisibilité du programme.

Personnellement, je n'utilise jamais ces instructions comme d'ailleurs je n'utilise jamais plus d'une instruction return par fonction. Ca ne plaît pas à tout le monde, c'est peut-être un manque de souplesse de ma part, mais je pense y gagner en lisibilité.

Thierry

une boucle infini ne signifie pas forcement plusieurs point de sortie... Aprés il est vrai que chacun possede ses propres habitudes de codages... On a tous nos préférences d'utilisation... personnelement lorsque j'ai besoin d'une boucle infini, je prefere utilisé un while(1) et un break qui me permet de sortir qd je veux alors qu'un changement de valeur qui va terminer toutes les instructions du while avant d'en sortir.

Citation:

---

Envoyé par nayah

, je prefere utilisé un while(1) et un break qui me permet de sortir qd je veux alors qu'un changement de valeur qui va terminer toutes les instructions du while avant d'en sortir.

---

ou rajouter tout un tas de if...

Citation:

---

Envoyé par Thierry Chappuis

L'utilisation d'une variable d'état (par opposition à l'usage d'instructions break) permet garantir que la boucle possède un seul point de sortie.

---

Si l'instruction break est unique, elle ne définit qu'un seul point de sortie aussi.
A l'inverse, une sortie sur variable d'état c'est très bien, mais si il y a 50 endroits dans la boucle où la variable est susceptible d'être affectée et/ou 20 autres où elle doit être testé pour diriger vers la fin de la boucle, je ne suis absolument pas convaincu que la lisibilité y gagne.

Comme souvent, quand on vise à transformer une règle qui a vocation à être utile en contrainte intangible, on obtient aisément le résultat contraire à celui cherché initialement.

Citation:

---

Envoyé par Bluedeep

Si l'instruction break est unique, elle ne définit qu'un seul point de sortie aussi.
A l'inverse, une sortie sur variable d'état c'est très bien, mais si il y a 50 endroits dans la boucle où la variable est susceptible d'être affectée et/ou 20 autres où elle doit être testé pour diriger vers la fin de la boucle, je ne suis absolument pas convaincu que la lisibilité y gagne.

Comme souvent, quand on vise à transformer une règle qui a vocation à être utile en contrainte intangible, on obtient aisément le résultat contraire à celui cherché initialement.

---

Si la variable d'état est affectée à 50 endroits dans la boucle, c'est avant tout un problème de conception.

Thierry

Sur ce point la je suis entierement d'accord. Une variable d'etat ne dois servir qu'a la sortie de la boucle... si on a vraiment besoin de cette variable pour un calcul a l'interieur de la boucle alors il est plus sage selon moi d'utiliser une variable intermédiaire... Mais je tiens a faire remarquer que lorsque je parle de boucle infini je parle de programme tournant en boucle sur une trés grande durée et susceptible de rencontrer une erreur. C'est a ce moment la que l'instruction break trouve son utilité car elle permet de quitter la boucle sans attendre la fin du bloc d'instruction.

Citation:

---

Envoyé par Thierry Chappuis

Si la variable d'état est affectée à 50 endroits dans la boucle, c'est avant tout un problème de conception.

Thierry

---

Et si le break n'est jamais atteint dans le cas d'une boucle infinie, c'est aussi un problème de conception... C'est le serpent qui se mord la queue, on en revient toujours au même point : si c'est fait "proprement", une boucle infinie ne poste aucun problème...

Citation:

---

Envoyé par Woufeil

Et si le break n'est jamais atteint dans le cas d'une boucle infinie, c'est aussi un problème de conception... C'est le serpent qui se mord la queue, on en revient toujours au même point : si c'est fait "proprement", une boucle infinie ne poste aucun problème...

---

Si on se limite à un seul break et que le flux du programme est clair, je n'ai aucun problème avec ça.

Thierry

Citation:

---

Envoyé par Bluedeep

Si l'instruction break est unique, elle ne définit qu'un seul point de sortie aussi.
A l'inverse, une sortie sur variable d'état c'est très bien, mais si il y a 50 endroits dans la boucle où la variable est susceptible d'être affectée et/ou 20 autres où elle doit être testé pour diriger vers la fin de la boucle, je ne suis absolument pas convaincu que la lisibilité y gagne.[...]

---

Si tu n'as qu'un break c'est que tu as déjà fait le travaille de conception qui mène à synthétiser une bonne variable de contrôle. Il y a un rapport direct (chez un bon programmeur) entre le nombre d'affectation et le nombre de break.

Bon, Garulfo, je vais te présenter un exemple, et tu me diras comment tu t'en sors :

Soit une boucle d'affichage de données en temps réel, présentant (un peu comme tu vois à la télé pendant la météo) des données évoluant dans le temps, où tu veux voir la variation dans le temps et non pas la superposition de l'ensemble. Le delai de temps est constant, mais le départ de la boucle se modifie chaque seconde..

L'utilisateur peut laisser cette boucle tourner 24/24, ou l'interrompre quand il le souhaite...

Comment fais-tu ?

Je n'aurais jamais pu croire qu'un debat sur le simple usage d'un while(1) ait pu succiter autant de vocations 8O

pour moi c'est au choix

Code:

---

1 2 3 4 5 6 7 8 9 10 11

bool continue_loop = true; while (continue_loop){ continue_loop = debat_avance(); post_mon_avis(); sleep(1); }

---

ou

Code:

---

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

while (1){ if (!debat_avance()){ break; } post_mon_avis(); sleep(1); }

---

Tes deux codes ne font pas la même chose : le premier fait un "post_mon_avis(); sleep(1);" de plus... Je pense que le second correspond plus à ton intention puisqu'il s'arrête dès qu'il estime que le débat n'a pas avancé. Ce qui illustre bien l'un des points que j'avais soulevé plus tôt : l'endroit où on veut arrêter la boucle n'est pas toujours au bout d'un des chemin d'exécution de la boucle et il faut alors faire des contortions pour passer à un modèle par variable :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

bool continue_loop = true; while (continue_loop){ if( debat_avance() ) { post_mon_avis(); sleep(1); else { continue_loop = false; } }

---

--
Jedaï

Citation:

---

Envoyé par souviron34

Bon, Garulfo, je vais te présenter un exemple, et tu me diras comment tu t'en sors :

Soit une boucle d'affichage de données en temps réel, présentant (un peu comme tu vois à la télé pendant la météo) des données évoluant dans le temps, où tu veux voir la variation dans le temps et non pas la superposition de l'ensemble. Le delai de temps est constant, mais le départ de la boucle se modifie chaque seconde..

L'utilisateur peut laisser cette boucle tourner 24/24, ou l'interrompre quand il le souhaite...

Comment fais-tu ?

---

Rapidement comme ça, je n'en sais rien. Mais je ne saurais pas le faire non plus rapidement avec un while(1) non plus. Rien à voir avec notre problème ici. De toute façon tout exemple donné ici sera probablement non significatifs. Je veux dire que si tu me passes un exemple et que je donne un équivalent sans boucle infini à interrompre, tu aurais raison de dire « un exemple réel est plus compliqué que ça » Ça ne mènera donc à rien ;)

Citation:

---

Envoyé par Jedai

[...]

Code:

---

1 2 3 4 5 6 7 8 9 10 11

bool continue_loop = true; while (continue_loop){ if( debat_avance() ) { post_mon_avis(); sleep(1); else { continue_loop = false; } }

---

---

Pourquoi pas plus simplement :

Code:

---

1 2 3 4 5 6

while (debat_avance()) { post_mon_avis(); sleep(1); }

---

??

et dans ce cas je ne vois pas ce que ça a de plus complexe que

Code:

---

1 2 3 4 5 6 7 8 9

while (1) { if (!debat_avance()) { break; } post_mon_avis(); sleep(1); }

---

Au contraire, c'est plus clair, plus concis et plus lisible !