Discussion :

[r0d]

Bonjour,

dans le code sur lequel je travaille en ce moment, je trouve beaucoup de boucles écrites dans le style:

Code :

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

1
2
3
4
5
6
7
bool stop_condition = false;
for(int i=0;i<10;++i)
{
   stop_condition = do_something();
   if (stop_condition==true)
      break;
}

Alors que j'ai toujours pensé qu'il serait préférable de procéder comme suit:

Code :

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

1
2
3
4
5
6
bool stop_condition = false;
int i=0;
while ( stop_condition==false && i<10 )
{
   stop_condition = do_something();
}

Seulement en y réfléchissant, j'ai du mal à argumenter sur les raisons qui font que le 2eme code est préférable au 1er. Selon vous, pour quelles raisons devons-nous préférer le 2eme exemple?

[Ehonn]

Si on met de côté l'utilisation de find_if.

J'ai un préférence pour :

Code :

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

1
2
3
4
for (auto const & e : v)
{
    if (do_something(e)) { break; }
}

Même si "détourne" l'utilisation d'une boucle for (nombre d'itérations connus). Je trouve cette solution pratique car elle limite le nombre et la portée des variables et est (très) lisible (je "triche" avec l'utilisation de C++11).
break et d'autres mots clefs de ce genre sont des éléments du langage qui existent, il sont puissants (et donc dangereux si on en abuse) mais peuvent et améliorer la lisibilité dans certains cas; il est dommage de s'en priver.

[ternel]

Pour moi, ca dépend de la nécessité de se souvenir de la raison de l'arret.
Si on s'en moque, le for-break me semble assez correct, avec la subtilité de préférer retourner true pour les succès

Code :

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

1
2
3
for(int i=0;i<10;++i) {
   if (!do_something()) break;
}

Si on veut s'en souvenir, je me demande bien pourquoi… vu qu'on a le RAII.

Les cas courants de boucle interrompues sont les détections (et comptage), et les erreurs.
Pour compter, on a effectivement aussi les std::find et std::find_if.

Abuser de RAII permet de tout nettoyer en partant, et donc permet les sorties rapides:

Code :

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

1
2
3
4
5
6
for(int i=0;i<10;++i) {
   if (!do_something()) return false;
}
for(int i=0;i<10;++i) {
   if (!do_something()) throw std::out_of_range("machin");
}

[therwald]

Si on veut s'en souvenir, je me demande bien pourquoi… vu qu'on a le RAII.

S'il s'agit d'un cas d'erreur, ça peut le faire, mais si ça fait partie de l'algorithme, je trouve préférable d'écrire les conditions de fin d'itération au même endroit. Il y a un compromis à trouver avec la lisibilité de l'instruction de boucle, effectivement, mais faire une boucle for classique dont la vraie condition de fin d'itération est ailleurs c'est vraiment savonner la planche au(x) pauvre(s) types qui devront relire plus-tard (voir à soi-même...la mémoire de ce genre de truc s’estompe vite avec le temps, et honnêtement il y a plus utile à faire de sa mémoire...)

[oodini]

Si la condition est effectivement à la toute fin du bloc, je ferais plutôt :

Code :

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

1
2
3
4
for (int i=0; i<10 && !stop_condition; ++i)
{
    ...
}

[Neckara]

Autant la présence de break dans des boucles while ne me gène pas vraiment, même si je préfère avoir si possible toutes les conditions de sorties de boucle en argument (ça se dit ? ) du while, c'est en général un peu plus lisible.

Autant pour le for, je m'interdit tout break.
En effet, pour moi le for, c'est un nombre d'itérations connu lors de l'entrée dans la boucle : On parcourt X éléments d'un conteneur ou on fait X tours.

Si le nombre d'itération à faire change dans la boucle ( break, condition déterminée par le retour d'une fonction, etc. ), je préfère utiliser un while.
Je trouve que c'est plus clair pour celui qui lit :
for = je te dit d'avance combien de tours on va faire
while = le nombre de tour peut être variable.

Après, il est vrai qu'avec le for du C++11, je me suis déjà autorisé un break ( un peu par flemme, je le reconnais ) mais je considère alors que c'est un cas d'erreur, un peu comme si je lançais une exception.