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.

[Luc Hermitte]

Je m'interdis personnellement d'interdire de faire du SEME et assimilé (break, return, continue).
On n'est plus en C, pas besoin de se rediriger à la fin d'un bloc pour y nettoyer des ressources. Le RAII est là pour ça.

r0d, si tu ne trouves pas argument en faveur du flag dans la boucle, c'est justement parce qu'il n'y en a aucun de valide ... en C++.

Bref, mon opinion sur le sujet, on la retrouve à ces divers endroits:
- http://www.developpez.net/forums/d23...iveau-methode/
- http://www.developpez.net/forums/d37...ondition-else/
- http://www.developpez.net/forums/d91...-continue-cpp/
- http://herbsutter.com/2013/05/13/got...orary-objects/

[r0d]

Merci à tous pour votre point de vue.

<HS>
punaise, quand je lis cette discussion, je me rend compte que je viens de loin... je débutais en c++ à l'époque et je ne faisais même pas la différence entre le C et le C++
</HS>

[oodini]

Un jour, tes souvenirs du C seront fumeux, et tu pesteras contre Visual avant de comprendre qu'il faut déclarer toutes tes variables au début du programme.

[Astraya]

Bonjour,

Entre ces deux codes, il y a de forte chance pour que le compilateur te donne le même assembleur une fois compilé. Les deux boucles sont assez simple donc facilement optimisable par le compilateur. Mais ce n'est pas dit pour une boucle plus complexe.
A voir l'assembleur final optimisé, mais je dirais kifkif.

Sinon pour ce qui est de la lecture de code, je privilégierais la visibilité des conditions de sortie, donc toute au début de la boucle que ça soit for ou while et non pas dans le corps de la boucle.

Cordialement,

[koala01]

Salut,

A vrai dire, je n'ai jamais écrit un break ou un continue dans une boucle en C++ (à moins, bien sur, qu'il n'y ait un switch... case dans la boucle )

Par contre, j'ai déjà souvent écrit un return, qu'il renvoie une valeur ou non (généralement, il en renvoie une vu que cette valeur sera utile ailleurs )

De manière générale, j'essaye généralement d'utiliser la boucle qui correspond le mieux à ce que je veux faire, c'est à dire:

La boucle "pour" si je dois travailler sur un "range" (que ce soit d'index ou d'itérateurs), la boucle "while" (voir do while) si je recherche une information particulière.

Je suis particulièrement critique, par contre, au fait de placer deux (ou plus) condition d'arrêt dans une boucle pour comme le propose oodini

[oodini]

Je suis particulièrement critique, par contre, au fait de placer deux (ou plus) condition d'arrêt dans une boucle pour comme le propose oodini

Subjectivité assumée, ou phase d'argumentation en préparation ?

[Klaim]

Mon avis sur les break/continue: http://programmers.stackexchange.com...es/58253#58253

When used at the start of a block, as first checks made, they act like preconditions, so it's good.

When used in the middle of the block, with some code around, they act like hidden traps, so it's bad.

Perso je prefere me permettre d'agencer le code au cas par cas de maniere lisible plutot que de suivre des dogmes.

[koala01]

Subjectivité assumée, ou phase d'argumentation en préparation ?

Subjectivité assumée

Autant je trouves "cohérent" d'avoir, par exemple, plusieurs conditions de sorties avec une boucle "while" (while (condition1 && condition2) ) autant j'estime que la seule condition de sortie d'une boucle pour devrait etre... la sortie de la plage de valeurs envisagées.

C'est d'ailleurs pour cela que je préférerai utiliser une boucle "while" (voire do while) pour créer une boucle (considérée comme) infinie, plutôt qu'une boucle "pour"