Discussion :

[gbdivers]

La boucle for face aux algorithmes de la bibliothèque standard

J'ai donné un jour un exercice à l'un de mes stagiaires : modifier tout le code d'un projet qu'il avait écrit pour remplacer toutes les boucles for par des algorithmes de la bibliothèque standard.

Au-delà de ma simple tendance naturelle à torturer les stagiaires, je trouvais cet exercice intéressant pour plusieurs raisons.
La première est pédagogique, pour habituer mon stagiaire à apprendre et à utiliser les outils existants de la bibliothèque standard plutôt que repartir systématiquement de zéro.
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.
La dernière raison est plus conceptuelle. Lorsque l'on conçoit son algorithme en terme de boucle for, on réfléchit en fait en terme d'implémentation. Penser en termes d'algorithmes de la bibliothèque standard, c'est penser en termes de concepts que l'on manipule. On obtiendra alors plus facilement du code propre, maintenable et évolutif.

Que pensez-vous de cette attitude de supprimer, sauf choix conscient et justifié, les boucles for du code au profit de la STL ?
Voyez-vous d'autres justifications ou contre-arguments pour l'utilisation systématique des algorithmes de la STL ?
D'un point de vue pédagogique, que pensez-vous de cet exercice ?
Dans un cadre professionnel, pensez-vous que cette règle soit utile ? Applicable ?
Avez-vous des exemples de code utilisant des boucles for qui ne pourraient pas être réécrits avec les algorithmes de la STL ?

[Matthieu Brucher]

Il y a souvent des boucles que j'implémenterai sous la forme de transform ou autres, mais ça me gonfle d'écrire :
- un foncteur, même si son nom sera bien précis et adapté
- une fonction lambda parce que mon IDE n'arrive pas à les parser correctement (merci Eclipse)

Maintenant, il m'arrive souvent aussi d'avoir à ajouter des compteurs à droite-gauche parce qu'un itérateur ne suffit pas, et dans ce cas, je ne sais pas trop comment utiliser un algorithme de la STL.

Bref, je sais qu'ils existent, mais je les utilise encore trop peu !

[Overcrash]

Bonsoir,

Bannir est un bien grand mot.

En C++ je pense que la différence entre un for et son équivalent en STL importe peu.
Je serais plus d'avis de laisser le développeur utiliser celui avec lequel il est plus à l'aise.

Par contre je suis curieux de voir qu'elle différence entre les deux, vitesse, monopolisation et co.

[JolyLoic]

J'aurais envie de répondre au sondage : Le plus souvent possible, mais pas plus ! Or le problème que j'ai est que si je me place en C++98, les alternatives aux boucles explicites me semblent encore bien pire.

Je crois que le seul algorithme qui de par la complexité de la boucle équivalente justifie que je l'utilise au lieu d'une boucle manuelle est le remove_if. Mais par exemple, for_each, j'ai essayé, et je suis revenu en arrière.

Maintenant, dans l'hypothèse C++11, la situation a changé. En bien.

Les lambdas rendent enfin les algorithmes de la STL utilisables. D'un autre côté, le range for loop présente quand il s'agit du cas très courant d'itérer sur un conteneur une syntaxe encore plus simple, plus directe et plus agréable que l'algorithme équivalent. Et même pour les boucles for classique, auto allège agréablement l'écriture.

Donc, en C++11, j'utiliserais par ordre de préférence :
- Le range for loop
- Un algorithme de la STL existant
- Une boucle for manuelle, que j'encapsulerait éventuellement dans un algorithme

Autant on peut dire que la programmation structuré a ouvert la guerre anti goto, que la programmation objet lutte farouchement contre if et switch, autant je ne pense pas que l'on soit arrivé au point où la boucle for soit à considérer comme à éviter, mais simplement on commence à avoir des alternative intéressantes pour les cas courants.

Certains langage vont plus loin que le C++ contre la boucle for, par exemple C# avec Linq, qui permet d'écrire du code qui travaille sur des données avec un philosophie proche du SQL (regroupement, tri, filtres...) sans expliciter les boucles nécessaires. Je n'ai pas encore réussi à me convaincre si au final je trouvais le résultat plus ou moins clair qu'avec les boucles explicites. Par contre, cette écriture ouvrait à des possibilités d'optimisation intéressantes.

[Rewpparo]

Personellement j'utilise peu les algos de STL. Même si je sais que je suis un peu rétrograde sur le sujet, j'ai plusieurs raisons pour ca.

La première est que j'aime pas les foncteurs. Ecrire une classe en plus c'est lourd, et en plus elle est souvent implémentée/définie dans une autre partie du fichier, ce qui oblige a scroller pour voir ce que ca fait exactement. Avec un for, on a tout sous les yeux.

Ensuite, le fait d'encapsuler une boucle dans un algo en fait oublier la complexité. Si tu tapes un for, tu vois partir tes cycles de processeurs et tu fais gaffe, alors qu'une ligne de code anodine passe facilement inapercue. Je sais bien que le fait d'encapsuler des algos compliqué dans les méthodes c'est notre taf, mais autant je sais que si j'appelle GraphicEngine::render() je sais que je vais y passer du temps, autant si une ligne de code dans une sous classe qui gère une liste, on réalise mieux sa complexité si on a le for sous les yeux.

Enfin, je trouve que les algos sont souvent overkill. Typiquement std::remove alors que tu sais que tu n'as qu'une instance de l'objet que tu veux enlever dans la liste.


Maintenant je ne suis pas vraiment au fait des nouvelles possibilités du C++11, et peut etre qu'il y a des trucs qui me simplifieraient la vie. Un jour peut etre.


Concernant l'exercice en lui même, je pense par contre qu'il est excellent. Choisir entre un algo STL et faire le for à la main doit être une décision informée. Pour ca, connaitre ces algos est indispensable, et cet exercice est un bon moyen d'apprendre. Moi même j'en aurais besoin.

[gbdivers]

Je pensais aussi au C++11, puisque les lambda sont pris en charge par gcc depuis 2 ans. Par contre, les range for sont plus récent dans gcc et je n'ai pas encore pris l'habitude des les utiliser.

Certains langage vont plus loin que le C++ contre la boucle for, par exemple C# avec Linq, qui permet d'écrire du code qui travaille sur des données avec un philosophie proche du SQL (regroupement, tri, filtres...) sans expliciter les boucles nécessaires. Je n'ai pas encore réussi à me convaincre si au final je trouvais le résultat plus ou moins clair qu'avec les boucles explicites. Par contre, cette écriture ouvrait à des possibilités d'optimisation intéressantes.

Je connais LINQ que de nom mais cela me fait penser à des fonctionnalités offertes par certaines bibliothèques pour le calcul distribué (MPI avec gather, scatter, etc.) ou le multi-threading (le premier exemple qui me vient est QtConcurrent, avec ses fonctions map, filter, reduce, etc.)
J'avais travaillé sur une lib qui offrait ces fonctionnalités pour le HPC (sur gpu et sur réseau) mais qui permettait de travailler aussi en mono cpu pour les tests. Ca permet de faire de jolies choses

[Obsidian]

La première est pédagogique, pour habituer mon stagiaire à apprendre et à utiliser les outils existants de la bibliothèque standard plutôt que repartir systématiquement de zéro. La seconde raison est une question d'expressivité. Lorsque l'on rencontre un for dans le code, on ne peut pas savoir 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.

Oui mais, en suivant ce raisonnement, il faudrait également retirer l'usage de while() et de do…while() qui ne sont pas très éloignées de for().

La dernière raison est plus conceptuelle. Lorsque l'on conçoit son algorithme en terme de boucle for, on réfléchit en fait en terme d'implémentation. Penser en termes d'algorithmes de la bibliothèque standard, c'est penser en termes de concepts que l'on manipule. On obtiendra alors plus facilement du code propre, maintenable et évolutif.

Tout le problème est là, à mon avis : ça part d'un bon sentiment mais ça introduit un effet pervers : sous prétexte d'inciter les gens à penser aux bons algorithmes, on risque en faite de leur désapprendre à y réfléchir eux-mêmes.

C'est un peu comme apprendre systématiquement et dès le départ à utiliser qsort(), en C, plutôt que de faire la moindre boucle pour trier ses éléments. Si ça se justifie en production (et que ça arrange bien tout le monde), les algorithmes de tri en eux-mêmes sont un passage incontournable dans toute formation supérieure en informatique.

C'est aussi faire l'hypothèse que les algos de la STL seront toujours plus adaptés et plus optimisé que ce que l'on pourra faire soi-même. C'est généralement vrai mais que ça ne peut l'être que jusqu'à un certain niveau. Or, si tout l'objet de l'approche consiste à utiliser au maximum des patterns tout faits en faisant abstraction de l'implémentation et du coût en ressources, alors je pense qu'il faut changer de langage. Et même, pourquoi pas, passer à un langage 100 % interprété, qui permet pour le coup de faciliter pas mal de facettes du paradigme objet, comme l'introspection.

Autant on peut dire que la programmation structuré a ouvert la guerre anti goto, que la programmation objet lutte farouchement contre if et switch, autant je ne pense pas que l'on soit arrivé au point où la boucle for soit à considérer comme à éviter, mais simplement on commence à avoir des alternative intéressantes pour les cas courants.

Je ne l'aurais pas mieux dit. Je pense que l'approche de GBDivers est justifiée mais qu'elle ne doit justement n'être qu'une « méthode » donnée de conduite d'un projet, mais pas forcément une ligne à suivre de manière universelle.

[koala01]

Salut,

J'ai voté "le plus souvent possible", mais je n'interdirai jamais l'utilisation des boucles (que ce soit une boucle for, while ou do while)

Les boucles et les itérations font, malgré tout, partie intégrante de la vie du programmeur, et si goto est apparu à l'époque, c'était, entre autres, pour permettre de les implémenter (tout en restant finalement fort proche de ce que faisait le processeur ).

Depuis, les boucles for, do while et while sont apparues suivies par des algorithmes particuliers (tel celui de remove_if) ou par des boucles qui ne font en définitive que simplifier l'écriture du code(une for range loop n'est en définitive qu'une boucle while qui se cache bien, et on peut parfaitement en dire autant des boucles for )

Les algorithmes existants permettent très certainement d'expliciter bien mieux qu'une boucle manuelle équivalente ce qui est fait et donc de faciliter la compréhension du code, cependant, certaines actions à effectuer dans les boucles restent à ce point "marginales" dans leur utilisation (dans le sens de "très improbablement réutilisables ailleurs que dans la fonction dans laquelle elles se trouvent ) que le cout de développement et de débugage que peut impliquer la "déportation" du code dans un foncteur effectuant le travail parait finalement excessif par rapport au bénéfice que l'on en tire.

Dieu m'est témoin (enfin, s'il existe, mais c'est un autre débat qu'il n'y a pas lieu d'avoir ici ) que je prêche en permanence pour le respect du principe de responsabilité unique!!!

Cependant, je reste tout à fait conscient que passé un certain niveau de complexité, la responsabilité unique puisse en fait être très importante en terme de conception.

Je n'ai, par exemple, jamais fait mystère de la prudence avec laquelle j'envisage le recours aux accesseurs et aux mutateurs.

Le fait de créer un foncteur permettant d'utiliser les boucles avancées risque grandement d'obliger le recours à ces types de fonctions, et donc, de nuire grandement au respect de Demeter.

Il resterait bien sur la possibilité de l'amitié, mais cette solution n'est applicable que pour un nombre limité d'objets: Si l'on en vient à devoir déclarer une dizaine (ou plus) d'amitiés pour permettre à tout qui doit accéder à des données particulière d'y accéder sans utiliser d'accesseur (ou pire de mutateur), il devient presque plus intéressant de passer tous les membres en accessibilité publique ... avec le risque d'oublier la mentalité objet qui consiste à s'intéresser plus aux comportements qu'aux données qui rendent ces comportements possible

Le tout, sans meme compter sur le fait que, si déport vers un foncteur sans amitié il y a, il faille compter sur une indirection supplémentaire et que cela représente malgré tout un cout à l'exécution, même en prenant toutes les mesures nécessaires pour essayer de le restreindre au minimum.

En résumé, je dirais : oui, usons et abusons sans vergogne des algorithmes existants, à la condition expresse que cela ne contrevienne cependant pas aux règles élémentaires de la programmation OO (respect de LSP, de SRP et de demeter en tête)

[3DArchi]

Salut,

Les algorithmes de la STL ont un gros avantage sur les boucles for : ils portent dans leur nom l'objectif même du traitement. La compréhension de l'objectif d'un sort, d'un find ou d'un fill est immédiate là où une boucle explicite (for/do/while) demande un examen plus détaillé. Je trouve que le code se lit alors de façon beaucoup plus fluide.

Je rajouterais que l'utilisation des algorithmes permet de ne se focaliser que sur les éléments importants du traitement : l'écriture du range et celui du foncteur/prédicat en mettant de côté l'implémentation effective de la boucle.

Clairement, les lambdas offrent une indéniable aide pour utiliser les algos plus 'naturellement' (les foncteurs old school à la C++98 ressemblant à des belles vérues et les constructions non triviales à coup de boost.bind pouvant effrayer). En revanche, bien que très enthousiaste au début, je ne suis plus si convaincu par les auto range loop auxquelles je préfère malgré tout les algorithmes (stl ou pas). Ceci dit, ils restent plus pratique qu'un simple for.

Pour ajouter un compteur à un itérateur, boost::zip_iterator avec boost::counting_iterator mais je reconnais que ça peut sembler plus artificiel.

[spidermario]

Certains langage vont plus loin que le C++ contre la boucle for, par exemple C# avec Linq, qui permet d'écrire du code qui travaille sur des données avec un philosophie proche du SQL (regroupement, tri, filtres...) sans expliciter les boucles nécessaires. Je n'ai pas encore réussi à me convaincre si au final je trouvais le résultat plus ou moins clair qu'avec les boucles explicites. Par contre, cette écriture ouvrait à des possibilités d'optimisation intéressantes.

En gros, c’est du sucre syntaxique sur map, filter et reduce. Ça vient de la programmation fonctionnelle et, effectivement, GHC (compilateur Haskell) semble faire des optimisations assez poussées sur ce genre de code.

Il s'agit de supprimer les boucles (for(;;) est plus rapide, while teste obligatoirement un flag)

Tu sais que les compilateurs actuels optimisent ça, n’est-ce pas ?

Voici le code produit par gcc pour while (1) {}, même en -O0 :

Code asm :

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

1
2
.L2:
        jmp     .L2

[ThomasCerq]

Le premier argument est compréhensible. Il est toujours bon pour un programmeur de savoir manipuler les différentes options qui sont à sa disposition.

Par contre, je pense que le deuxième argument ne tient pas la route. Ce qui est fait à l'intérieur de la boucle doit être expliqué dans des commentaires si le code ne se suffit pas à lui même. Il ne faut pas confondre les structures algorithmiques avec lisibilité du code.

Le dernier argument ne tient pas davantage. La conception est une chose. L'implémentation une autre. Il est important de bien séparer les deux (qui peuvent d'ailleurs être gérées par deux personnes différentes). La conception ne doit pas être faite en pensant à la manière dont ce sera implémenté. Et les outils algorithmiques utilisés ne doivent pas être influencés par la manière dont l'algorithme a été conçu.

Voilà mon avis.

[Invité]

Il s'agit de supprimer les boucles (for(;;) est plus rapide, while teste obligatoirement un flag)

Cette question est strictement académique
Obliger des élèves à utiliser des bibliothèques leur permet de les connaitre et de les utiliser à bon escient ensuite.

Mais un jour , il devront bien produire et pour cela sortir du schéma d'apprentissage pour rechercher un résultat. Admettons qu'ils restent en C++ au lieu de partir vers java C# etc... On écrit généralement du C++ dans un contexte commercial pour :
1. La vitesse d’exécution
2. L'accès au C et au bas niveau machine

Dans ce contexte un dev C++ est plus souvent confronté aux limites du hardware qu'un autre. Il est évident qu'ils n'aura pas les réflexes de librairie qu'on peut avoir dans des langages de plus haut niveau.

D'autre part, le fait de réécrire une fonction de bibliothèque permet d'y ajouter ses propres contrôles, interruptions, tests, ... Les boucles , les if , les goto ont leur strict équivalent dans le jeu d'instruction processeur.

Il y a donc bien un intérêt à utiliser les librairies et un intérêt à les bypasser. Il suffit d'un if(...) break; à l'intérieur du for après une initialisation pour justifier la réécriture d'une fonction de librairie.

Cela dit , je ne suis pas très académique et dans mon job, j'ai tendance à faire chauffer au rouge les CPU ..... Très loin des programmes qui pourraient être écrits en C# , je "descends" beaucoup en C , et fais pas mal de debug assembleur.

Dans une logique de base de données stricte , où le C# ferait à peu près le même boulot , vous pouvez vous permettre de philosopher , moi pas trop

[Klaim]

Mais un jour , il devront bien produire et pour cela sortir du schéma d'apprentissage pour rechercher un résultat. Admettons qu'ils restent en C++ au lieu de partir vers java C# etc... On écrit généralement du C++ dans un contexte commercial pour :
1. La vitesse d’exécution
2. L'accès au C et au bas niveau machine

3. Cross platform.
4. Certains languages sont interdit sur certaines plateformes, pas le C++.
5. Consommation mémoire réduite (voir Hip Hop pour les points 1 et 5)
6. Prédictabilité (temps-réél et semi-temps réél)
7. Non attaché à une société en particulier / standardisé
8. Nombre, variété & qualité des bibliothèques

etc.

Il y a bien plus que la vitesse d'execution et l'accès bas niveau comme raison de choisir cette catégorie de language.

[Invité]

3. Cross platform.
4. Certains languages sont interdit sur certaines plateformes, pas le C++.
5. Consommation mémoire réduite (voir Hip Hop pour les points 1 et 5)
6. Prédictabilité (temps-réél et semi-temps réél)
7. Non attaché à une société en particulier / standardisé
8. Nombre, variété & qualité des bibliothèques
etc.

Je suis archi d'accord mais j'essayais d'être concis par rapport aux situations exceptionnelles qu'il faut gérer en prod contrairement à l'apprentissage où on est constamment dans la simulation et particulièrement en france où on fait beaucoup de gestion ce qui pourrait changer avec la montée de l'embarqué (µcontrolleurs) et les robots

Se passer du for n'a absolument aucun sens dans ce contexte

Beaucoup de spécificités du C++ sont héritées du C (link statique, agencement du segment data...)

@kolodz

Votre exemple montre bien l'exercice de simulation. Par contre dans un contexte d'apprentissage, vous devriez considérer l'emploi des expressions régulières. L'usage des strchr() strstr() strtok() et leurs eqv objet, en cascade donne un code mal sécurisé et difficile à maintenir.

Je dis ça car c'est un critère d'embauche dans mon cas. Cela dit , dans de nombreux cas , le find() ou strchr() suffit..

[Bktero]

Mes cours de C++ sont allés assez loin (polymorphismes et autres héritages multiples que j'ai tout oublié) mais n'ont pas abordés la STL. Venant du C et l'utilisant tout le temps comparé au C++, je n'ai jamais creusé le contenu de la STL et je ne connaissais pas ces techniques !

Je vais me renseigner dessus à l'occasion, ça a l'air intéressant

Une question néanmoins : je vois bien l'intérêt lorsque la boucle est très longue et comportement beaucoup de code. L'intérêt n'est-il pas limité pour les boucles simples, comme celle mise en exemple à la page précédente ? Le gain est-il en lisibilité / maintenabilité ou y a t-il un gain de performances (d'après ce que j'ai lu dans ce thread, ce n'est pas évident) ?

[barmic]

Je viens apporter ma contribution. Personnellement que ce soit en C++ ou dans n'importe quel autre langage pour moi c'est à peu près pareil, j'utilise ce qui à mon sens est le plus expressif, c'est à dire dans l'ordre de préférence :

• une méthode d'une bibliothèque s'il en existe une adaptée
• une méthode de la bibliothèque standard (ou STL pour le cas du C++)
• une construction à base de for_each, si le cas si prête bien (j'itère sur toute la liste, sans break)
• for, si j'ai bien un pattern initialisation/test de sortie/incrémente (ou autre)
• while ou do .. while si rien de ce qui précède n'a sa place

Et plus je descends dans cette liste, plus je commente. Parce qu'au moins le code est expressif.

Pour moi il y a deux arguments à cela :

• les méthodes « classiques » sont plus expressives et comme disent certains un code simple l'est suffisament pour se passer de commentaire
• pour moi réutiliser l'existant est à la fois l'essence de l'informatique (ça doit servir à nous simplifier la vie !)
• je présume que les gens qui ont écris la bibliothèque standard ou pas, se sont plus pris la tête que moi ou sont meilleurs que moi et on écris une code de meilleur qualité que le miens

Si un jour cela me pose un problème de performance ou pour la gestion des accès concurrent alors je m'attellerais à avoir un algorithme qui possède les propriété dont j'ai besoin mais par défaut je ne vais pas le faire de manière préventive.

Cela vient aussi du fait que j'aime beaucoup les constructions de perl comme :

Code :

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

say join ';', map { $_ * 2} split /_/, '2_3_4';

[Klaim]

Le premier argument est compréhensible. Il est toujours bon pour un programmeur de savoir manipuler les différentes options qui sont à sa disposition.

Par contre, je pense que le deuxième argument ne tient pas la route. Ce qui est fait à l'intérieur de la boucle doit être expliqué dans des commentaires si le code ne se suffit pas à lui même. Il ne faut pas confondre les structures algorithmiques avec lisibilité du code.

Le dernier argument ne tient pas davantage. La conception est une chose. L'implémentation une autre. Il est important de bien séparer les deux (qui peuvent d'ailleurs être gérées par deux personnes différentes). La conception ne doit pas être faite en pensant à la manière dont ce sera implémenté. Et les outils algorithmiques utilisés ne doivent pas être influencés par la manière dont l'algorithme a été conçu.

Voilà mon avis.

Je suis loin d'être de cet avis.

D'abord, un nom de fonction qui dit explicitement ce que fait le code est à la fois plus clair, plus court et plus sur que n'importe quel commentaire.
D'ailleurs le commentaire à de fortes chances de devenir obsolète voir dangereux avec le temps. Les commentaires sont important, mais ils sont en réalité le dernier recours pour faire du code lisible/compréhensible rapidement.

Par contre, je ne vois pas l'intérêt de virer les boucles for, c'est comme si on nous demandais si on ne devrais pas virer les int parce qu'on a une classe Int qui fait le boulot bien mieux.

Elle va être implémentée comment la boucle for?
Et l'algorithm for_each on l'implémente comment? Il ne marche pas de la même façon que la boucle for each du langage... et il faut bien des primitives pour l'écrire!

Enfin bref, la question en elle même n'apporte rien je trouve, mais pointer le fait que les algorithms de la STE deviennent tout a coup super utiles et simplifient beaucoup l'accès à la clarté du code est une bonne chose.
De mon expérience avec les lambda, ça change juste la vie.

[Bousk]

Bonjour,

autant avec les lambdas je trouve ça très pratique à utiliser;
autant sans, devoir écrire un foncteur et m'y référer pour comprendre ce qui est fait par cette seule ligne, je trouve que ça n'apporte rien.
Comme un commentaire plus haut, j'aime avoir le code réalisé dans ma boucle sous les yeux.

Mes 2 centimes.

[shenron666]

Quelqu'un peut me donner l'équivalent de ceci avec la stl ?

Code :

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

1
2
for(int i=0; i < myArray.Count; ++i)
    myArray[i] = GenerateSomething(myArray[i], i);

histoire de savoir si c'est possible avec autant voire moins de code

[gbdivers]

Quelqu'un peut me donner l'équivalent de ceci avec la stl ?

Code :

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

1
2
for(int i=0; i < myArray.Count; ++i)
    myArray[i] = GenerateSomething(myArray[i], i);

histoire de savoir si c'est possible avec autant voire moins de code

Tu prends un exemple de code minimaliste, où l'on a besoin d'avoir l'indice, on reste donc sur de la boucle for quasiment classique. Il y a quand même beaucoup d’algorithmes qui n'ont pas besoin de connaître i (et pour rappel, [] n'est pas ce qu'il y a de plus performant en terme d'accès)

Donc dans tous les cas, il faudra créer cette variable, ce qui ne permet pas de réduire proprement le code

Code :

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

1
2
3
4
5
6
7
// avec range-based for
int i = 0;
for (auto& value, myArray) { value = GenerateSomething(value, i++); }
 
// avec for_each et lambda
int i = 0;
for_each (begin(myArray), end(myArray), [&i] (auto& value) { value = GenerateSomething(value, i++); });

Donc clairement, si tu pars d'un code minimaliste, l'utilité sera très limité