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.

[JolyLoic]

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).

Tu pourrais détailler un peu cet avis ?

Déjà qu'entends tu par "auto range loop" ? Est-ce bien le "range-based for statement" ? Si oui, je ne comprends pas trop pourquoi tu le compares aux algorithmes en général, puisqu'il n'est pour moi sensé remplacer qu'un seul algorithme, for_each. Ou alors peut-être veux tu dire que tu l'as vu utilisé là où des algorithmes plus spécialisés auraient été adaptés ?

[koala01]

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).

Tout à fait, mais les algorithme de la STL restent... génériques.

Je veux dire par là qu'ils couvrent certes des fonctionnalités récurrentes et utiles dans bien des applications, mais qu'il te faut parfois, dans le domaine propre du business pour lequel tu développes ton projet, que tu doives itérer d'une manière qui ne correspond à aucune des cas "bateaux" envisagée par la STL, ou peut etre parce que la logique pour chaque itération est trop importante pour tenir dans une lambda...

Bind, qu'il vienne de boost ou non, c'est très bien, à condition que tu ne binde qu'une ou deux expressions, car si tu fais des boost.bind de boost.bind de boost.bind, comme j'ai déjà eu l'occasion de lire certains code, je peux te jurer que le code est sans conteste techniquement très beau, mais devient rapidement totalement incompréhensible

La méthode techniquement très belle devient alors contre productive par rapport à une méthode qui utilise une simple boucle, quelle qu'en soit la nature

[3DArchi]

Tu pourrais détailler un peu cet avis ?

Déjà qu'entends tu par "auto range loop" ? Est-ce bien le "range-based for statement" ? Si oui, je ne comprends pas trop pourquoi tu le compares aux algorithmes en général, puisqu'il n'est pour moi sensé remplacer qu'un seul algorithme, for_each. Ou alors peut-être veux tu dire que tu l'as vu utilisé là où des algorithmes plus spécialisés auraient été adaptés ?

Il y a un peu de ça. Disons que c'est effectivement une amélioration du for classique d'autant que c'est une construction qu'on trouve dans d'autres langages il me semble et que ça peut ainsi faciliter les aller-retours. Au départ, c'était ces aspects qui m'avaient séduit. Mais, au final, souvent dans le code auquel j'ai été confronté, la boucle for trouve un équivalent dans un algo. Donc, je préfère utiliser et préconiser l'utilisation de l'algo plutôt que de la simple boucle for (d'autant si on n'a pas besoin de passer par un foncteur mais qu'on peut le faire via un lambda (ou un simple bind en C++98)).
On pourrait se poser la question pour le for_each versus for.

[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

[guigz2000]

Bannir le for du C++?
LOL....Plus serieusement,Non...

Plusieurs raisons:
1..Le for est une construction intrinseque au language.La STL en revanche est une librairie.Comme toute librairie elle peux etre changée et evoluer alors que le for classique ne changera pas. En plus sur certain compilateurs a la noix, la STL n'est pas toujours parfaitement supportée ou implementée.

2..J'aimerai bien voir un microbenchmark d'une boucle for et d'un equivalant STL.Je doute que au niveau performance cela soit vraiment similaire

3..Au niveau complexité, remplacer un élément de language par une librairie a tendance a me hérisser le poil,sauf si on attends une fonctionnalité bien spécifique et vraiment plus complexe.Cela aura tendance systematiquement a générer un microcode moins compact et plus lourd a l'execution.Meme si un compilateur optimise bien cela aura dans tous les cas une incidence sur la taille et la vitesse du code.Un algo reste un algo et il est souvent implementé lui meme avec des boucles for,while,etc...Il utilise des variables supplementaire, occupe de la memoire et contient troutes sortes de tests pas forcements necessaire pour l'utilisation voulue.En plus,un appel de fonction n'as jamais de consequences nulles au niveau performances.

4.. Pour ce qui est de la facilité de lecture, un commentaire expliquant une boucle for un peu complexe est souvent suffisant.

J'ai vraiment l'impression que dans la plupart des cas,utiliser la STL pour remplacer des constructions simples (dans ce cas une boucle for) reviens vraiment a utiliser un marteau pour tuer une mouche.Ca marche mais on prends le risque de se taper sur les doigts ou d'avoir une tendinite.

[ManusDei]

Je ne comprend pas la question. Je pourrais avoir un exemple (avec for, sans for) ?

[kolodz]

Ces méthode sont un support à la gestion des listes/collections.

Bon exemple serai donc :

Code :

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

1
2
3
4
5
6
iterator i = find (c.begin(), c.end(), value);
// is the same as
iterator i;
for ( i=c.begin(); i!=c.end(); ++i ) {
  if (*i==value) break;
}

C'est en effet plus clair. Sur d'autre langage, ce genre de méthode existe.
Mais on ne considère pas cela comme un remplacement du "for".

D'ailleurs, un langage qui ne dispose pas d'un find "standard". Il sera probablement crée une fonction réalisant l'opération, par le développeur.*

Cordialement,
Patrick Kolodziejczyk.

[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.

[bugsan]

Réponse: method extract + nommer correctement cette méthode.

[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.