Salut tous.
En lisant certains messages j'ai remarqué avec un certain étonnement que
plusieurs personnes ont l'air de ne pas trop aimer l'instruction break.
-je pense qu'ils doivent penser la meme chose pour continue-
Je dit que ca m'etonne car jusqu'ici j'avais plutot l'habitude de m'en
servir relativement souvent (pour sortir des boucles je parle. pas
uniquement dans les switch).
En fait étant donné que ce n'est pas souvent que je remet en question ma
facon de programmer, et que c'est peut etre un manque (?), je me dit
voila l'occasion de reflechir un peu, mais pas tout seul. alors voila je
vous demande:
Qu'est-ce que vous, très personnellement, vous pensez de break ?
et aussi, qu'est-ce que vous en pensez tres objectivement ? (Quelle
devrait etre la maniere générale de s'en servir)
j'ajoute quand meme quelques details:
apparament sa s'approche un peu de l'utilisation des boucles et demies,
la aussi comme j'ai lu des critiques qui divergaient un peu j'ai essayé
de regarder le problème d'encore plus loin:
dans un langage (ici le C++) on met a notre disposition un jeu
d'instructions. c'est bien. heureusement avec il y a une notice
d'utilisation. c'est ce qui va nous permettre de réaliser des
algorithmes, pour modéliser des réactions logiques en fonction de causes
(variables).
Et vu de la on se dit alors, puisqu'on a cet outil a disposition, en
fait, n'importe comment que l'on dispose nos instructions, si
l'algorithme est réalisé on a atteind le but recherché.
si on a que ca, alors tout est permi.
si on ajoute une restriction d'optimisation et de temps de frappe
(économie du nombre de lignes) alors on arrive a un modele de
programmation qui dépendrait de la maniere de penser de chaque personne.
reste alors le critere de lisibilité, c'est lui qui est mis en question
dans ce thread finallement non ?
c'est pour ce dernier et unique critere que break est des fois accepté
et des fois non ? pas vrai ? vous pensez que j'ai raison ?
est-ce que ce critere là est-il finalement pas un bridage de l'esprit
des programmeurs ?
bon j'espere que vous allez pas me prendre pour un troll, moi je me pose
certaines question, si je cherche a répondre tout seul je risque de pas
prendre les bonnes directions, alors voila je fait appel a vous, merci.
bool bSortir = false; while(!bSortir) { if( test_condition_de_bord) bSortie = true; else if(test_autre_condition_de_sortie) bSortie = true; // etc... qq else if sur chaque test qui peut mettre fin à la boucle else {...} // ici le code executé dans la boucle }
plus propre, Ah ?
certes, lisible même avec 36 else if... j'aime assez ;-) Evidement, ici c'est brut mais ce type de truc évite la plupart du temps break/continue et les imbrications, peu lisibles il est vrai.
Pour moi, break c'est de l'assembleur ;-) on dirait presque un goto / JMP. A éviter, à mon avis.
Je ne vois pas en quoi le code que tu as posté est préférable à un break : Dans les deux cas, on est obligé de lire le contenu de la boucle pour savoir ses conditions de sorties, c'est plus lourd à écrire, ça demande des variables de plus, ya plein d'imbriquations...
Alors j'admet que ce code peut présenter des avantages par rapport à du break (encore que l'imbrication des if est peu élégante à mon goût)).
C'est pour ça que je ne fais pas souvent de switch, j'aime pas trop comme il est implémenté.
Comment sais-tu comment switch est implémenté ?
Et pi y marche que sur des int.
Euh, pas vraiment, même si effectivement il ne marche pas pour tout, il permet bien d'autres types que des int.
-- Loïc
Alexandre wrote:
une solution du genre :
bool bSortir = false;
while(!bSortir)
{
if( test_condition_de_bord)
bSortie = true;
else if(test_autre_condition_de_sortie)
bSortie = true;
// etc... qq else if sur chaque test qui peut mettre fin à la boucle
else
{...} // ici le code executé dans la boucle
}
plus propre,
Ah ?
certes, lisible même avec 36 else if... j'aime assez ;-)
Evidement, ici c'est brut mais ce type de truc évite la plupart du temps
break/continue et les imbrications, peu lisibles il est vrai.
Pour moi, break c'est de l'assembleur ;-) on dirait presque un goto / JMP.
A éviter, à mon avis.
Je ne vois pas en quoi le code que tu as posté est préférable à un break
: Dans les deux cas, on est obligé de lire le contenu de la boucle pour
savoir ses conditions de sorties, c'est plus lourd à écrire, ça demande
des variables de plus, ya plein d'imbriquations...
bool bSortir = false; while(!bSortir) { if( test_condition_de_bord) bSortie = true; else if(test_autre_condition_de_sortie) bSortie = true; // etc... qq else if sur chaque test qui peut mettre fin à la boucle else {...} // ici le code executé dans la boucle }
plus propre, Ah ?
certes, lisible même avec 36 else if... j'aime assez ;-) Evidement, ici c'est brut mais ce type de truc évite la plupart du temps break/continue et les imbrications, peu lisibles il est vrai.
Pour moi, break c'est de l'assembleur ;-) on dirait presque un goto / JMP. A éviter, à mon avis.
Je ne vois pas en quoi le code que tu as posté est préférable à un break : Dans les deux cas, on est obligé de lire le contenu de la boucle pour savoir ses conditions de sorties, c'est plus lourd à écrire, ça demande des variables de plus, ya plein d'imbriquations...
Alors j'admet que ce code peut présenter des avantages par rapport à du break (encore que l'imbrication des if est peu élégante à mon goût)).
C'est pour ça que je ne fais pas souvent de switch, j'aime pas trop comme il est implémenté.
Comment sais-tu comment switch est implémenté ?
Et pi y marche que sur des int.
Euh, pas vraiment, même si effectivement il ne marche pas pour tout, il permet bien d'autres types que des int.
-- Loïc
Christophe Lephay
Alexandre wrote:
"Marc Espie" a écrit dans le message de
Il y a aussi toutes ces boucles ou la condition d'arret s'exprime au milieu de la boucle qui donnent naturellement des
while (1) { debut_de_boucle(); if (cond) break; fin_de_boucle(); } <snip>
une solution du genre :
bool bSortir = false; while(!bSortir) { if( test_condition_de_bord) bSortie = true; else if(test_autre_condition_de_sortie) bSortie = true; // etc... qq else if sur chaque test qui peut mettre fin à la boucle else {...} // ici le code executé dans la boucle }
plus propre, certes, lisible même avec 36 else if... j'aime assez ;-) Evidement, ici c'est brut mais ce type de truc évite la plupart du temps break/continue et les imbrications, peu lisibles il est vrai.
Pour moi, break c'est de l'assembleur ;-) on dirait presque un goto / JMP. A éviter, à mon avis. C'est pour ça que je ne fais pas souvent de switch, j'aime pas trop comme il est implémenté. Et pi y marche que sur des int.
Ceci dit, ta solution ne fait pas la meme chose que ce dont parle Marc. Avec ton approche, son code se réécrirait :
Personnellement, je trouve la boucle plus lisible avec les breaks dans ce cas précis...
Chris
Alexandre wrote:
"Marc Espie" <espie@tetto.gentiane.org> a écrit dans le message de
Il y a aussi toutes ces boucles ou la condition d'arret s'exprime au
milieu de la boucle qui donnent naturellement des
while (1) {
debut_de_boucle();
if (cond)
break;
fin_de_boucle();
}
<snip>
une solution du genre :
bool bSortir = false;
while(!bSortir)
{
if( test_condition_de_bord)
bSortie = true;
else if(test_autre_condition_de_sortie)
bSortie = true;
// etc... qq else if sur chaque test qui peut mettre fin à la
boucle else
{...} // ici le code executé dans la boucle
}
plus propre, certes, lisible même avec 36 else if... j'aime assez ;-)
Evidement, ici c'est brut mais ce type de truc évite la plupart du
temps break/continue et les imbrications, peu lisibles il est vrai.
Pour moi, break c'est de l'assembleur ;-) on dirait presque un goto /
JMP. A éviter, à mon avis.
C'est pour ça que je ne fais pas souvent de switch, j'aime pas trop
comme il est implémenté. Et pi y marche que sur des int.
Ceci dit, ta solution ne fait pas la meme chose que ce dont parle Marc. Avec
ton approche, son code se réécrirait :
Il y a aussi toutes ces boucles ou la condition d'arret s'exprime au milieu de la boucle qui donnent naturellement des
while (1) { debut_de_boucle(); if (cond) break; fin_de_boucle(); } <snip>
une solution du genre :
bool bSortir = false; while(!bSortir) { if( test_condition_de_bord) bSortie = true; else if(test_autre_condition_de_sortie) bSortie = true; // etc... qq else if sur chaque test qui peut mettre fin à la boucle else {...} // ici le code executé dans la boucle }
plus propre, certes, lisible même avec 36 else if... j'aime assez ;-) Evidement, ici c'est brut mais ce type de truc évite la plupart du temps break/continue et les imbrications, peu lisibles il est vrai.
Pour moi, break c'est de l'assembleur ;-) on dirait presque un goto / JMP. A éviter, à mon avis. C'est pour ça que je ne fais pas souvent de switch, j'aime pas trop comme il est implémenté. Et pi y marche que sur des int.
Ceci dit, ta solution ne fait pas la meme chose que ce dont parle Marc. Avec ton approche, son code se réécrirait :
Personnellement, je trouve la boucle plus lisible avec les breaks dans ce cas précis...
J'ai déjà vu (vu, pas écrit) du code qui utilisait une fausse boucle juste pour pouvoir se servir de break :
do { traitement_1(); if (bSortir) break;
traitement_2(); if (bSortir) break;
traitement_3(); if (bSortir) break;
traitement_4();
} while (0);
-- ___________ 2003-11-13 09:11:26 _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Il faut donc que les hommes commencent -'(__) par n'être pas fanatiques pour mériter _/___(_) la tolérance. -- Voltaire, 1763
Le jeudi 13 novembre 2003 à 00:03, Christophe Lephay a écrit dans
fr.comp.lang.c++ :
Personnellement, je trouve la boucle plus lisible avec les breaks dans ce
cas précis...
J'ai déjà vu (vu, pas écrit) du code qui utilisait une fausse boucle
juste pour pouvoir se servir de break :
do
{
traitement_1();
if (bSortir)
break;
traitement_2();
if (bSortir)
break;
traitement_3();
if (bSortir)
break;
traitement_4();
} while (0);
--
___________ 2003-11-13 09:11:26
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Il faut donc que les hommes commencent
-'(__) par n'être pas fanatiques pour mériter
_/___(_) la tolérance. -- Voltaire, 1763
Personnellement, je trouve la boucle plus lisible avec les breaks dans ce cas précis...
J'ai déjà vu (vu, pas écrit) du code qui utilisait une fausse boucle juste pour pouvoir se servir de break :
do { traitement_1(); if (bSortir) break;
traitement_2(); if (bSortir) break;
traitement_3(); if (bSortir) break;
traitement_4();
} while (0);
-- ___________ 2003-11-13 09:11:26 _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Il faut donc que les hommes commencent -'(__) par n'être pas fanatiques pour mériter _/___(_) la tolérance. -- Voltaire, 1763
amerio
J'ai déjà vu (vu, pas écrit) du code qui utilisait une fausse boucle juste pour pouvoir se servir de break :
do { traitement_1(); if (bSortir) break;
traitement_2(); if (bSortir) break;
traitement_3(); if (bSortir) break;
traitement_4();
} while (0);
Ca ressemble furieusement à un try/throw/catch local. Si c'est pour compenser sur un vieux compilo, pourquoi pas ? Ou bien dans un innerloop, là où lever une exception serait trop couteux... (un break ne coute rien comparé à un try/catch)
Perso, je pense qu'il faut etre pragmatique, et non dogmatique. On va vite vers la guerre de religion, sinon. (mais les dogmes ont du bon, aussi, hein ! :->)
J'ai déjà vu (vu, pas écrit) du code qui utilisait une fausse boucle
juste pour pouvoir se servir de break :
do
{
traitement_1();
if (bSortir)
break;
traitement_2();
if (bSortir)
break;
traitement_3();
if (bSortir)
break;
traitement_4();
} while (0);
Ca ressemble furieusement à un try/throw/catch local.
Si c'est pour compenser sur un vieux compilo, pourquoi pas ?
Ou bien dans un innerloop, là où lever une exception serait trop couteux...
(un break ne coute rien comparé à un try/catch)
Perso, je pense qu'il faut etre pragmatique, et non dogmatique.
On va vite vers la guerre de religion, sinon.
(mais les dogmes ont du bon, aussi, hein ! :->)
J'ai déjà vu (vu, pas écrit) du code qui utilisait une fausse boucle juste pour pouvoir se servir de break :
do { traitement_1(); if (bSortir) break;
traitement_2(); if (bSortir) break;
traitement_3(); if (bSortir) break;
traitement_4();
} while (0);
Ca ressemble furieusement à un try/throw/catch local. Si c'est pour compenser sur un vieux compilo, pourquoi pas ? Ou bien dans un innerloop, là où lever une exception serait trop couteux... (un break ne coute rien comparé à un try/catch)
Perso, je pense qu'il faut etre pragmatique, et non dogmatique. On va vite vers la guerre de religion, sinon. (mais les dogmes ont du bon, aussi, hein ! :->)
Lightness1024!
amerio wrote:
Perso, je pense qu'il faut etre pragmatique, et non dogmatique. On va vite vers la guerre de religion, sinon. (mais les dogmes ont du bon, aussi, hein ! :->)
Perso, je pense qu'il faut etre pragmatique, et non dogmatique.
On va vite vers la guerre de religion, sinon.
(mais les dogmes ont du bon, aussi, hein ! :->)
Perso, je pense qu'il faut etre pragmatique, et non dogmatique. On va vite vers la guerre de religion, sinon. (mais les dogmes ont du bon, aussi, hein ! :->)
Perso, je pense qu'il faut etre pragmatique, et non dogmatique. On va vite vers la guerre de religion, sinon. (mais les dogmes ont du bon, aussi, hein ! :->)
Les dogmes n'ont du bon que si on est pragmatique...
Chris
amerio wrote:
Perso, je pense qu'il faut etre pragmatique, et non dogmatique.
On va vite vers la guerre de religion, sinon.
(mais les dogmes ont du bon, aussi, hein ! :->)
Les dogmes n'ont du bon que si on est pragmatique...
Perso, je pense qu'il faut etre pragmatique, et non dogmatique. On va vite vers la guerre de religion, sinon. (mais les dogmes ont du bon, aussi, hein ! :->)
Les dogmes n'ont du bon que si on est pragmatique...
