Faut-il bannir le for du C++ ? [Débat]

**koala01** · 04/04/2012, 12h08

Envoyé par galerien69

Déjà le stagiaire, il est là aussi pour apprendre. Donc lui faire endosser la part de productivité, c'est un peu gros.

Je crois qu'il faut lui apprendre à etre productif, malgré tout, étant donné que c'est quand meme ce qu'il devra faire par la suite (une fois sorti du stage)...

Si l'on se contente de le placer dans une situation "d'exercice de style", il n'y a plus aucun avantage à faire un stage par rapport à ce qu'il trouve à l'école, non plus

Il ne faut en effet pas s'attendre à ce qu'il soit aussi productif que quelqu'un qui a ne serait ce que deux ou trois ans d'expérience, mais l'idée est quand meme de lui permettre de faire son expérience et que son employeur puisse profiter de ce que le stagiaire met au point, meme s'il le fait peut etre plus lentement qu'un autre

En plus, il est parfois bien plus compétent que les employés techniquement parlant.

plus compétant que certains, très certainement, sous condition quand meme (s'il a eu un bon prof, qui ne lui a pas appris le C With Classes, s'il a eu des cours corrects de POO, si... )

Mais il faut qu'il puisse se heurter à la "dure réalité" et travailler sur du code de production aussi, car, c'est une chose de partir "de rien" et donc d'avoir une liberté de choix, mais c'en est une autre que de devoir assumer des choix qui ont été faits par d'autres qui, avec un peu de malchance, ne sont plus dans la boite depuis bien longtemps

Et enfin même un employé lambda est aussi là pour apprendre. Après qu'il s'en tape c'est une autre affaire.

Je crois que l'informatique, c'est comme le domaine médical: il faut se tenir très sérieusement à jour, et surtout, etre en mesure de se remettre en question

Quant à Qt, ca me semble normal de préférer l'utilisation des structures de Qt pour Qt avant l'emploi de la stl...

Je ne suis pas du tout d'accord avec toi...

Les structures de Qt sont particulièrement bien faites, mais elles présentent malgré tout un inconvénient majeur: elles sont propres à Qt...

Si tu bases ta partie "business" sur Qt, toute ton application va dépendre de Qt, et tu n'auras pas d'autre choix, si, pour une raison ou une autre, tu décides un jour de changer de bibliothèque, que de "tout casser" et de reprendre ton projet à zéro.

Cela pourrait etre considéré comme l'occasion de "faire mieux", mais cela implique que l'ensemble du développement est à refaire malgré tout, et donc un temps de refonte important.

Par contre, si tu limites la dépendance envers Qt à la partie "vue" (et à une partie de l'aspect "contrôleur"), tu restes beaucoup plus libre de changer de point de vue, voire, d'utiliser le business pour une application totalement différente, utilisant une autre bibliothèque IHM

**yan** · 04/04/2012, 14h36

Envoyé par koala01

Les structures de Qt sont particulièrement bien faites, mais elles présentent malgré tout un inconvénient majeur: elles sont propres à Qt...

Si tu bases ta partie "business" sur Qt, toute ton application va dépendre de Qt, et tu n'auras pas d'autre choix, si, pour une raison ou une autre, tu décides un jour de changer de bibliothèque, que de "tout casser" et de reprendre ton projet à zéro.

Pourtant Qt n'est pas que de l'IHM.
Ce que tu dit est pareil pour n'importe quel framework. Remplace Qt par Boost dans ton paragraphe par exemple et se sera tout aussi vrai;p

Juste pour dire, que choisir un framework pour l'exploiter au maximum as aussi beaucoup d'avantage. Voir peut être plus que moins (ou pas

).

Par exemple (comme on parle de Qt) pour un de mes dernier projets on as décidé de baser l'application entièrement sur Qt. En l'exploitant au maximum j'ai :
* des threads avec eventloop
* des communications inter thread par event ou signal/slot
* des manipulations d'objet par des algo concurrent
* des states machines
* des plugins
* un cache
* des QVariant(sorte de void* typé)
* des meta data.
* un peux de 3D
* de l'affichage d'image char, short, float, complexe, bayer,...
* des smart pointeurs et des lambda dans des QVariant.
* de l'IHM

Pour faire fonctionner tout cela, j'ai dû utiliser 3 mutex au maximum pour optimiser 2-3 petites choses. Et au finale, la partie GUI de Qt n'est qu'une petite partie de l'application. Au contraire Qt à permis une architecture multi thread très robuste et très facilement extensible par plugin.

Invité · 03/04/2012, 08h33

Envoyé par air-dex

Excellent dans le cadre de l'apprentissage de la STL. Et puis c'est bon pour ce qui est de ne pas réinventer la roue.

Je ne vois pas très bien en quoi écrire :

Code :

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

for(int i=0;i<sz;i++) fait_qqch(v[i]);

consiste davantage à réinventer la roue (ou est moins expressif que)

Code :

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

1
2
3
4
5
6
7
for_each(v.begin()v.end(),op);
 
... (ailleurs dans le code, généralement loin)
 
struct faire_qqch {
   void operator()(int i) {fait_qqch(i);}
} op;

On pourrait également débattre sur la vertu de "ne pas réinventer la roue". Neuf fois sur dix, ce "précepte" veut dire : utiliser LA librairie que JE connais (tu citais Qt...), et prétendre que LA première solution au problème que j'ai trouvée est la seule possible.

Mon expérience, c'est qu'en général, le code devient bon à la deuxième ou troisième itération. Imposer à des étudiants l'idée que "réinventer la roue" est un péché mortel me parait un peu dangereux. (Je suis bien évidemment d'accord que ce n'est pas une excuse pour ne pas connaitre la STL, ou récrire sa classe string...)

Pour que l'idée soit bonne, il faudrait que TOUS les développeurs C++ aient un très bon niveau en STL.

Pour bien utiliser la STL (ses algorithmes et ses conteneurs, tout au moins), il faudrait que les développeurs aient une bonne compréhension de l'algorithmique, et des garanties fournies par les différents conteneurs et algorithmes. On est loin du compte...

Francois

**JolyLoic** · 03/04/2012, 09h05

Envoyé par fcharton

Je ne vois pas très bien en quoi écrire :

Code :

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

for(int i=0;i<sz;i++) fait_qqch(v[i]);

consiste davantage à réinventer la roue (ou est moins expressif que)

Code :

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

1
2
3
4
5
6
7
for_each(v.begin()v.end(),op);
 
... (ailleurs dans le code, généralement loin)
 
struct faire_qqch {
   void operator()(int i) {fait_qqch(i);}
} op;

Là, tu biaise un peu la situation :
- Tu choisis l'algorithme qui a le moins de valeur ajoutée par rapport à un for (car il n'est que parcourt)
- Tu l'utilise dans un contexte C++98 où les algorithmes sont peu utilisables.

En C++11, ton code s'écrirait avec les algorithmes :

Code :

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

1
2
3
4
for_each(v.begin()v.end(),[](int i)
    {
        fait_qqch(i);
    });

Ou plus simplement avec une range for loop :

Code :

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

for(int i : v) fait_qqch(i);

Invité · 03/04/2012, 09h13

Envoyé par JolyLoic

En C++11, ton code s'écrirait avec les algorithmes :

Code :

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

1
2
3
4
for_each(v.begin()v.end(),[](int i)
    {
        fait_qqch(i);
    });

Ou plus simplement avec une range for loop :

Code :

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

for(int i : v) fait_qqch(i);

Du coup, je ne suis pas certain de comprendre l'intérêt... On n'est pas dans le pur raccourci d'écriture?

EDIT : par ailleurs, je ne crois pas qu'on puisse dire que ces deux écritures "éliminent le for", le "compteur de boucle" (i dans l'exemple) est toujours dans l'appel, et le code du for se trouve dans la boucle. On se limite ici à un bricolage syntaxique, pas très différent de celui qui consisterait à bannir les for... pour les remplacer par des while()...

Francois

**Klaim** · 03/04/2012, 10h19

- racourcis
- donner un nom a l'action
- pas de bug dans l'implémentation (de la boucle)

**air-dex** · 03/04/2012, 23h41

Envoyé par galerien69

cette phrase me révolte.
Déjà le stagiaire, il est là aussi pour apprendre. Donc lui faire endosser la part de productivité, c'est un peu gros.
En plus, il est parfois bien plus compétent que les employés techniquement parlant.
Et enfin même un employé lambda est aussi là pour apprendre. Après qu'il s'en tape c'est une autre affaire.

Je suis d'accord qu'un stagiaire est aussi là pour apprendre. Et il est même surtout là pour ça.

Mais cet apprentissage ne se limite pas à un approfondissement de la technique enseignée en cours. Un stage permet aussi (et surtout) de développer son expérience de la vie en entreprise (dont la productivité, à mon avis) et de découvrir d'autres sujets que ceux vus en cours. Or je ne vois pas en quoi passer ses journées le nez dans cplusplus.com à chercher des équivalents à ses boucles FOR aide à apprendre à travailler vite et bien et à apprendre à être productif.

Envoyé par galerien69

Quant à Qt, ca me semble normal de préférer l'utilisation des structures de Qt pour Qt avant l'emploi de la stl...

Je suis parfaitement d'accord. Le plus important dans ce que je veux dire n'est pas d'utiliser Boost dans un programme avec Boost ou Qt dans un programme Qt. C'est que pendant qu'on utilise Boost ou Qt, on n'utilise pas la STL et on l'oublie. Or cette conaissance parfaite de la STL est pour moi une condition nécessaire au banissement de la boucle for au profit des algos de la STL dont il est sujet dans ce thread.

Envoyé par fcharton

On pourrait également débattre sur la vertu de "ne pas réinventer la roue". Neuf fois sur dix, ce "précepte" veut dire : utiliser LA librairie que JE connais (tu citais Qt...), et prétendre que LA première solution au problème que j'ai trouvée est la seule possible.

Quand je parle de ne pas réinventer la roue, je parle de regarder s'il existe des librairies sur le sujet à ne pas réinventer et en quoi elles peuvent résoudre ton problème. Et quand je dis "regarder s'il existe des librairies", je ne dis pas "prendre nécessairement LA librairie que JE connais". Tant mieux si t'en connais déjà une très bonne mais c'est toujours bien de faire un petit état de l'art avant de choisir une librairie (ou ton code).

Dans le cadre de l'apprentissage des algos de la STL, bannir les for au profit des algos permet à celui qui apprend de voir s'il n'y a pas DES algorithmes qui font mieux que ses boucles FOR. D'où mon "ne pas réinventer la roue".

**gbdivers** · 03/04/2012, 23h57

Envoyé par air-dex

Mais cet apprentissage ne se limite pas à un approfondissement de la technique enseignée en cours. Un stage permet aussi (et surtout) de développer son expérience de la vie en entreprise (dont la productivité, à mon avis) et de découvrir d'autres sujets que ceux vus en cours. Or je ne vois pas en quoi passer ses journées le nez dans cplusplus.com à chercher des équivalents à ses boucles FOR aide à apprendre à travailler vite et bien et à apprendre à être productif.

C'est inquiétant si une personne mais une journée complète à lire une seule page, non ?
Concernant la productivité à longue terme (donc pas juste le temps pour coder les quelques lignes de code, mais en prenant compte aussi du debogage, de la maintenance, de l'évolution, etc.), il est beaucoup plus productif d'utiliser quelque chose de robuste (la STL) que du code from scratch

Invité · 04/04/2012, 01h39

Envoyé par air-dex

Quand je parle de ne pas réinventer la roue, je parle de regarder s'il existe des librairies sur le sujet à ne pas réinventer et en quoi elles peuvent résoudre ton problème.

Je crois que tout le monde fait cela de nos jours. J'ai connu des gens qui avaient leurs librairies perso sur tout et n'importe quoi, et redéveloppaient presque tout, mais c'était il y a très longtemps.

Il me semble au contraire qu'on tombe souvent, aujourd'hui, dans l'excès inverse (et pas seulement en informatique, d'ailleurs). Je vois souvent des gens qui à l'énoncé d'un problème, n'importe lequel, se précipitent sur google, ou leur site préféré, pour essayer de voir si "quelqu'un a déjà fait cela".

Ca part d'un bon sentiment, mais ça donne souvent de mauvais résultats, parce qu'on essaye de trouver une solution toute faite avant d'avoir correctement diagnostiqué le problème, et qu'on finit, presque toujours, par adapter le problème à la solution...

Et c'est précisément ce qui m'ennuie avec les parties de haut niveau (en fait, abstraites) de la STL. Elles sont souvent très séduisantes intellectuellement, mais comme elles remplacent un problème concret par une version plus abstraite de celui ci, elles font payer très cher les erreurs de diagnostic.

C'est pour cela que je parlais de réécrire. Souvent, il est plus efficace d'essayer de commencer à résoudre à la main un problème (parfois sans coder, d'ailleurs), et de ne faire un état de l'art, ou décider d'employer tel ou tel outil de haut niveau, que quand on est certain d'avoir compris de quoi on parle.

Envoyé par gbdivers

Concernant la productivité à longue terme (donc pas juste le temps pour coder les quelques lignes de code, mais en prenant compte aussi du debogage, de la maintenance, de l'évolution, etc.), il est beaucoup plus productif d'utiliser quelque chose de robuste (la STL) que du code from scratch

Si la STL répond au problème posé, et est correctement utilisée, c'est certain.

Cependant, je trouve qu'il y a un certain danger à penser trop vite en terme de "haut niveau" (ici d'algorithmes), parce que cela risque de figer certains éléments de la conception avant d'avoir correctement diagnostiqué le problème.

C'est un peu le problème qu'on rencontrait aux beaux jours de l'approche objet, quand on se précipitait pour construire une hiérarchie de classes avant d'avoir fini l'analyse. On perdait souvent, ensuite, un temps précieux à revenir sur ces erreurs initiales. On retrouve ce genre de problème aujourd'hui quand quelqu'un essaie, trop fort et trop tôt, d'exprimer un problème en terme de design patterns.

Je crois que les algorithmes (ceux de haut niveau, du moins) sont plus utiles dans un second temps, quand le problème est à peu près dégrossi, et qu'il s'agit de passer d'un code initial, souvent bricolé et fait main, à quelque chose de plus abstrait, qui sera plus durable et évolutif.

Francois

**rhludovic** · 03/04/2012, 09h07

Que pensez-vous de cette attitude de supprimer, sauf choix conscient et justifié, les boucles for du code au profit de la STL ?

C'est parfois utile et intéressant, mais ne doit pas se faire systématiquement.

D'un point de vue pédagogique, que pensez-vous de cet exercice ?

Pour les débutants, il faut avoir cette polyvalence. Savoir utiliser divers méthode pour résoudre un même problème.

Dans un cadre professionnel, pensez-vous que cette règle soit utile ? Applicable ?

Comme pour la première question, ça peut être utile dans certaines circonstances.

Avez-vous des exemples de code utilisant des boucles for qui ne pourraient pas être réécrits avec les algorithmes de la STL ?

Ce n'est pas que c'est toujours possible que c'est forcément utile ou la meilleur solution. Il possible de faire le tour de france a vélo ou en voiture. Le choix dépend des circonstances.

**bizulk** · 03/04/2012, 14h00

foreach() optimisé ? Ca dépend de l'implémentation ( voir ici)
Je trouve qu'avec ces conteneurs et autres mécanismes sensés nous aider pour les parcours de données on tombe facilement dans des pièges boueux ralentissant considérablement l'exécution.
On simplifie peut-être la lecture du code en apparence, et finalement si l'on souhaite optimiser on se retrouve souvent à considérer le type de données utilisé pour le parcours et à connaître l'implémentation des outils.

Avec des méthodes simplistes il n'y a que peu de règles à respecter pour éviter ces soucis de performances.

Finalement je rejoins d'autres avis qui explique que l'importance si situe derrière l'outil

**deuz59** · 04/04/2012, 12h25

Cela rejoint parfaitement mon point de vue qui se résume en "Penser du QUOI vers le COMMENT plutôt que l'inverse"

Pour ce faire, tout plein de bonnes questions et bonnes pratiques sont recensées dans ce bouquin dont je ne cesserai jamais de recommander la lecture :
http://www.scribd.com/doc/50311486/coder-proprement

Quoi de plus frustrant quand on cherche à corriger/faire évoluer un programme que d'avoir à deviner ce que ça fait à travers ce qu'y est fait.
La bonne démarche serait que le code nous amène d'abord à comprendre ce qui est fait pour cibler précisément le bout de code à revoir, le "comment ça le fait et pourquoi ça le fait pas bien"

L'informatique est un MOYEN et la solution de facilité revient trop souvent à se réfugier dans ses connaissances et donc d'en faire trop tôt un BUT (peut être aussi la faute à la formation qui devrait être davantage orientée dans ce sens ???)

Un idéal serait de réussir à faire d'abord un squelette de code avec que des appelles de méthodes aux noms explicites,avec une organisation par niveau d'abstraction et seulement au niveau le plus bas mettre un petit TODO "à implémenter" ==> sorte de DSF qui ne resterait au final qu'à (faire) implémenter, si toutefois aucune API existante ne propose pas déjà une implémentation toute faite

**skypers** · 04/04/2012, 14h54

Je trouve que l'argument conceptuel est le plus important dans le message de l'OP. Entre une grosse for pour compter le nombre d'occurences matchant un critère et un std::count_if, il n'y a pas photo pour moi.

En revanche, je trouve curieux l'étonnante façon qu'ont les gens d'utiliser des lambdas simples qui rendent le code plus long et moins trivial alors qu'une boucle aurait suffit. Coder reste un art, tous les outils sont bons, il faut juste savoir les utiliser au bon endroit. C'est toujours la même histoire.

**singman** · 05/04/2012, 01h25

La seconde raison est une question d'expressivité. Lorsque l'on rencontre un for dans le code, on ne peut pas savoir ce que va faire ce code. Il est nécessaire de lire le contenu du bloc et cela peut devenir très complexe, surtout si on appelle beaucoup de fonctions et que l'on manipule de nombreux objets dans ce bloc.

Alors là, je pense qu'on touche le fond...
Déjà l'idée d'interdire le for() est stupide (oui, stupide mais je pense encore plus).
Mais vouloir faire croire qu'utiliser la STL rend le code plus expressif ! Non mais je dois rêver, vous avez apprit le C comment ? La compréhension de ce que fait un code n'est JAMAIS dans le code lui même, quelque soit le langage, mais dans la manière dont il est écrit.
Il faut commenter, expliquer, éviter les astuces personnelles, se conformer au standard de l'entreprise pour laquelle on développe.

Ce sondage est simplement un non-sense. Et vous êtes prof ?

**JolyLoic** · 05/04/2012, 02h41

Puisque je suis la personne citée, je vais répondre, même si ce n'est pas moi qui ait ouvert cette discussion et que j'ai l'impression qu'une partie des reproches lui est adressée.

Envoyé par singman

Alors là, je pense qu'on touche le fond...
Déjà l'idée d'interdire le for() est stupide (oui, stupide mais je pense encore plus).

Encore une fois, l'idée n'a jamais pour moi été d'interdire, mais de déconseiller, et a contrario de conseiller les alternatives.

Envoyé par singman

Mais vouloir faire croire qu'utiliser la STL rend le code plus expressif !

Je le dis et le maintiens. Et je vais donner quelques exemples, avec des algorithmes simples (c'est à dire qu'avec des algorithmes plus complexes, l'intérêt est encore plus grand).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
void fctFor1(vector<double> const &notes)
{
	int nombreElèvesPassant = 0;
	for (size_t i = 0 ; i<notes.size() ; ++i)
	{
		if (notes[i] >= 10)
		{
			nombreElèvesPassant++;
		}
	}
	cout << "Elèves passant : " << nombreElèvesPassant << endl;
}
 
void fctStl1(vector<double> const &notes)
{
	int nombreElèvesPassant = count_if(notes.begin(), notes.end(), [](double d){return d>=10;});
	cout << "Elèves passant : " << nombreElèvesPassant << endl;
}

Ici, j'ai hésité à supprimer la variable intermédiaire. Dans du vrai code, elle disparaîtrait probablement. Le code STL permet immédiatement de savoir que l'on va compter. En plus, on veut une valeur, on appelle une fonction, c'est direct. J'aurais aimé pouvoir le simplifier en count_if(notes, [](d){return d>=10;});, mais le C++ ne permet pas encore ça.
Le code à base de for ne s'écrit plus comme une fonction, mais comme un bout de code modifiant une variable locale. On remplace une fonction pure par du code statefull, ce qui est généralement moins clair.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
void fctFor2(vector<double> notes)
{
	display(notes);
	for (size_t i = 0 ; i<notes.size() ; ++i)
	{
		if (notes[i] < 0)
		{
			notes[i] = 0;
		}
	}
	display(notes);
}
 
void fctStl2(vector<double> notes)
{
	display(notes);
	replace_if(notes.begin(), notes.end(), [](double d){return d<0;}, 0);
	display(notes);
}

Mêmes principe. Dans du vrai code, j'écrirais probablement un commentaire avant le for, je n'en verrai pas l'utilisé avant le replace_if : il ne ferait que paraphraser le code.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
void fctFor3(vector<double> const &notes)
{
	for (size_t i = 0 ; i<notes.size() ; ++i)
	{
		if (notes[i] < 10)
		{
			cout << "Je n'ai pas une classe de génies" << endl;
			return;
		}
	}
	cout << "J'ai une classe de génies" << endl;
}
 
void fctStl3(vector<double> const &notes)
{
	if (all_of(notes.begin(), notes.end() , [](double d){return d>=10;}))
	{
		cout << "J'ai une classe de génies" << endl;
	}
	else
	{
		cout << "Je n'ai pas une classe de génies" << endl;
	}
}

Envoyé par singman

Non mais je dois rêver, vous avez apprit le C comment ?

Je n'ai jamais vraiment appris le C, mais je ne vois pas le rapport.

Envoyé par singman

La compréhension de ce que fait un code n'est JAMAIS dans le code lui même, quelque soit le langage, mais dans la manière dont il est écrit.
Il faut commenter, expliquer, éviter les astuces personnelles, se conformer au standard de l'entreprise pour laquelle on développe.

Je ne suis pas entièrement d'accord avec la première partie de la phrase. Par exemple les commentaires décrivent non pas ce que fait le code, mais ce que la personne l'ayant écrit croyait qu'il faisait. Quand il s'agit d'utiliser du code, les commentaires suffisent généralement. Quand il s'agit de le déboguer ou de le faire évoluer, ils ne sont plus suffisants, et un code écrit clairement devient alors un atout majeur.

Mais surtout pour moi les commentaires les plus intéressants sont ceux qui sont donnés non pas par // ou /* */ mais par des noms de variables ou de fonctions expressifs. Et on rejoint un des deux reproches que je fais à for : Il est tellement générique qu'il n'aide pas à comprendre dans quel objectif une boucle a été écrite (le deuxième étant qu'il est tellement générique qu'il est facile de se planter dans son utilisation). On peut certes mettre un commentaire avant le for, mais ça revient pour moi à utiliser des variables nommées v1, v2, v3 et à commenter à côté de la déclaration que v1 est le prix unitaire, v2 la quantité et v3 l'âge du vendeur.

Envoyé par singman

Ce sondage est simplement un non-sense. Et vous êtes prof ?

Je suis avant tout développeur. Je donne un enseignement mais ce n'est pas mon activité principale. Par contre, j'ai pu constater grâce à ça qu'avant que l'entraînement et l'habitude ne viennent contrecarrer ça, les débutants se trompent régulièrement dans l'écriture d'une boucle for. Ce qui est en soi signe que c'est un des éléments complexes du langage, et donc une source de bugs, même dans du vrai code.

**Bousk** · 05/04/2012, 10h46

Je me demandais, est-il possible avec une telle écriture (for range loop, foreach, ...) de réaliser un break et sortir de la boucle plus tôt ?
Bien que je suppose qu'il s'agisse d'une mauvaise pratique.

**cob59** · 05/04/2012, 11h25

Envoyé par Bousk

Je me demandais, est-il possible avec une telle écriture (for range loop, foreach, ...) de réaliser un break et sortir de la boucle plus tôt ?
Bien que je suppose qu'il s'agisse d'une mauvaise pratique.

Ça dépend du rôle du break dans la boucle for.
Souvent, il s'agit de parcourir des éléments jusqu'à ce que l'un réponde à une condition/un prédicat. Dans ce cas-là, un std::find_if peut suffire.

**Bousk** · 05/04/2012, 11h55

Effectivement c'est le cas le plus courant.

Mais une autre utilisation m'interpelle:
quid de réaliser une action sur un élément externe : faire une somme des éléments, remplir un autre tableau qu'on utilisera en sortie de boucle ?
Jusqu'à présent tous les exemples montrent l'utilisation de l'élément actuellement parcouru sans action sur un élément externe à lui-même.

Utiliser for_each avec une classe qui enregistre le résultat en membre sur lequel réaliser un get à la fin ?

Code :

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

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
// for_each example
#include <iostream>
#include <algorithm>
#include <vector>
using namespace std;
 
struct somme {
  myclass() : result(0) {}
  void operator() (int i) { result += i; }
  int result;
};
 
int main () {
  vector<int> myvector;
  myvector.push_back(10);
  myvector.push_back(20);
  myvector.push_back(30);
 
  somme myobject;
  for_each (myvector.begin(), myvector.end(), myobject);
 
  cout << myobject.result << endl;
 
  return 0;
}

? D'après l'exemple fourni sur http://www.cplusplus.com/reference/algorithm/for_each/
Je trouve ça un peu lourd comme opération. Enfin ces "soucis" de lourdeur sont en grande partie améliorés par les lambdas (vivement que je puisse les utiliser

)

**cob59** · 05/04/2012, 12h31

Dans ce cas-là on s'intéressera plutôt à std::accumulate avec std::plus<int>() comme BinaryOp.

**spidermario** · 05/04/2012, 15h45

Envoyé par Bousk

Effectivement c'est le cas le plus courant.

Mais une autre utilisation m'interpelle:
quid de réaliser une action sur un élément externe : faire une somme des éléments, remplir un autre tableau qu'on utilisera en sortie de boucle ?
Jusqu'à présent tous les exemples montrent l'utilisation de l'élément actuellement parcouru sans action sur un élément externe à lui-même.

Utiliser for_each avec une classe qui enregistre le résultat en membre sur lequel réaliser un get à la fin ?

C++11 dispose maintenant de fonctions lambda avec fermeture :

Code c++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#include <iostream>
#include <algorithm>
#include <vector>
#include <cstdlib>
 
int main() {
    std::vector<int> myvector;
    myvector.push_back(10);
    myvector.push_back(20);
    myvector.push_back(30);
 
    int somme;
    for_each(myvector.begin(), myvector.end(), [&somme](int x) {
        somme += x;
    });
 
    std::cout << somme << std::endl;
 
    return EXIT_SUCCESS;
}