Faut-il bannir le for du C++ ?

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.

Je partage un peu aussi cet avis. Un aglo de la STL est tellement plus sexy qu'un for. Mais dans la vrai vie, l'utilisation des foncteurs déclaré comme une struct à l’extérieur de la fonction courante sont très lourd, parfois extrêmement compliqué ( appel sur un vecteur de pointeur vers une fonction membre de l'objet). Après la dernière version de C++ permet peut-être cela plus simplement.

Pour info Microsoft à implémenté un SQL like (LINQ) pour remplacé les for, mais je trouve ce mélange C#/SQL vraiment sale.

Un autre probleme qui m'arrive, lorsque l'on fait une boucle avec le besoin d'avoir un identifiant (la valeur de i), j'ai parfois utilisé std::distance() pour la calculé mais la boucle for dans ce cas correspond finalement mieux aux besoins.

Citation:

---

Envoyé par Klaim

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

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 ! 8O

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

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:

---

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

---

avec les boucles FOR, une chose est certaines :
NE JAMAIS mettre la condition dans la syntaxe boucle mais toujours en dehors !

ne jamais faire :

Code:

---

1 2	for (a=1;a<count(mavariable);a++) {...}

---

mais toujours

Code:

---

1 2 3

borne=count(mavarialbe) for (a=1;a<borne;a++) {...}

---

sinon suivant la taille du tableau, la mémoire est constament réutilisée, recachée,estimée...

bref une énorme perte de temps, de ressources et de performance !

Avis aux codeurs fous du PHP et de python !

pour ma part iterer sur un tableau avec du size_t i=0, ca me choque pas.
Pas plus que sur un string avec l'operateur []

Je prefere ca, parce que declarer des iterators (mine de rien), ca prend de la place.
Jaime pas declarer en dehors de ma boucle (prob de scope) et j'aime pas gaspiller des lignes (accolades de scope, +declaration de literateur). Et ca tient pas a l'interieur de la boucle for...si on code en 80 caracteres.

Bref, pour les array et structure avec operator[] (string, deque,...) je prefere utilise la bonne vieille incrementation, et je ne crois pas quon perde en semantique. Au contraire...

Citation:

---

Envoyé par galerien69

Je prefere ca, parce que declarer des iterators (mine de rien), ca prend de la place.
Jaime pas declarer en dehors de ma boucle (prob de scope) et j'aime pas gaspiller des lignes (accolades de scope, +declaration de literateur). Et ca tient pas a l'interieur de la boucle for...si on code en 80 caracteres.

---

Programmeur........

Didonc, si on te demande de faire 50000 fois le tour d'une place et de compter à chaque fois le nombre d'ordure dans les poubelles, ça te plaîrait ?
Si tu sais qu'à chauqe tour de place, personne n'a mis ou vider de poubelle, est-ce que tu vas recompter ? non ? alors pourquoi tu le fais (en mettrant ton compteur dans la boucle for) c'est une perte de temps énorme.

@Michael remy, je n'ai strictement rien compris de tes 2 dernières contributions... 8O

Code:

---

1 2 3

borne=count(mavarialbe) for (a=1;borne<10;a++) {...}

---

il y a plus simple pour réaliser une boucle infinie :aie:
a < borne plutôt non ?
ou ta boucle se charge de décrémenter borne ?
tout cela n'est pas clair

Tous les getSize() de la stl sont const et en temps constants, la "seule perte" c'est l'appel supplémentaire.
Et dans ce cas on privilégiera cette écriture amha

Code:

---

for (int i = 0, t = vec.size(); i < t; ++i) {}

---

Je ne crois pas qu'on puisse parler des algorithmes de la STL comme d'un tout.

J'ai l'impression qu'il y a en fait quatre catégories très différentes :

1- des templates de fonctions très utilisées (min, max, swap)
2- des fonctions de librairie standard utilisant le modèle des conteneurs et des itérateurs (copy, filll, remove, erase, find)
3- des algorithmes au sens habituel du terme (sort, partition, stable_sort, les opérations sur ensembles binaires)
4- un assemblage de méthodes permettant une progammation générico-fonctionnelle (transform, bind, inner_product,...)

Personnellement, j'ai tendance à utiliser souvent le groupe 1. Ce sont des algorithmes triviaux, qui n'apportent rien au code, mais ça devient vite une habitude.

Je me méfie du groupe 2: en général, les opérations efficaces d'un conteneur sont implémentées comme des fonctions membres, et les algorithmes "standard" ont une furieuse tendance à devenir sous-optimaux quand on fait évoluer les conteneurs sous jacents.

J'utilise systématiquement le groupe 3, mais suis toujours étonné par le nombre de programmeurs qui ne comprennent pas la différence entre sort et stable_sort, ou quand il faut utiliser partition, ou comment on utilise sort pour indexer des données qu'on ne veut pas trier.

La catégorie 4, où se trouvent la plupart des fonctions pouvant éliminer les boucles, m'a toujours parue suspecte. D'abord parce que je ne crois pas qu'un for_each() soit plus expressif qu'un for(; ; ). Pour des boucles "normales" (c'est à dire de quelques lignes, quelques dizaines au plus), qui ne sont utilisées qu'une fois (ou tellement courte qu'il n'est pas nécessaire de les centraliser) je préfère nettement voir, quand je débugue, la boucle dans son contexte que de jouer au "code dont vous êtes le héros", en sautant d'une fonction à l'autre (voire d'un foncteur à l'autre, avec leurs constructeurs, leurs surcharges, etc.). Aussi, parce que dans du code existant, majoritairement non fonctionnel, cette approche complique gratuitement l'existant (je ne l'ai jamais vue simplifier le code, en pratique), et que si le but est d'écrire en fonctionnel, je choisirais d'autres langages (le J dans mon cas).

Francois

Citation:

---

Programmeur........

Didonc, si on te demande de faire 50000 fois le tour d'une place et de compter à chaque fois le nombre d'ordure dans les poubelles, ça te plaîrait ?
Si tu sais qu'à chauqe tour de place, personne n'a mis ou vider de poubelle, est-ce que tu vas recompter ? non ? alors pourquoi tu le fais (en mettrant ton compteur dans la boucle for) c'est une perte de temps énorme.

---

peux-tu développer avec un exemple concret plutot qu'une analogie foireuse? Parce que si on me demande de compter, moi je compte. :mrgreen:

Citation:

---

J'ai l'impression qu'il y a en fait quatre catégories très différentes :

---

je ne fais aucune différence entre la catégorie 1 (que tu utilises au plus) et la catégorie 4 (qui te rebute). Pour moi, c'est que des fonctions "globales" que je n'utilise que si la doc est bien détaillée, et que la fonction est livrée dans un "tout" a peu pres utile.

Quant au for_each, je l'aime bien. Je suis incapable de m'en passer en js, ou php (et même en java quand j'eus été contraint d'utiliser ce langage). Mais bon, en c++, foreach, des que y a quelques itérateurs qui se courent après, c'est la déclaration au dessus, donc au final ca sert à rien je trouve (je parle pour boost_foreach)

Bonsoir,

je ne m'aventurerais pas à donner un avis sur le fait qu'il faille bannir le for du c++ au profit de la stl, bien que j'imagine que la réponse soit négative pour de multiples raisons qui doivent m'échapper pour la plupart. De plus, je ne connais pas suffisamment la stl pour émettre un avis critique dessus.

Il y a tout de même un argument en faveur de for qui me vient naturellement à l'esprit, mais je vais l'exprimer sous la forme d'une question car je ne suis pas sûr qu'il soit recevable :

bannir le for du c++ n'empêcherait-il pas les programmeurs d'adapter leurs codes à leurs architectures?

Je m'explique un peu parce que la question est très certainement mal formulée et assurément trop vague. Pour ceux qui aiment ou besoin de le faire, il est possible d'améliorer significativement les performances des codes de calcul en jouant avec les boucles (déroulage, fusion, scission, etc). Le compilateur procède déjà à ce genre d'optimisation mais il est souvent possible de faire beaucoup mieux. Peut-être ai-je tort mais il me semble qu'en faisant du haut niveau (stl), cela n'est plus possible.

Plus généralement, c'est justement le fait de pouvoir faire à la fois du bas et du haut niveau qui me plaît dans le C++. Je pense que je me détournerais de ce langage si l'un de ces deux aspects venait à disparaître au profit de l'autre.

ben le bannir du langage non. C'est complètement utopique.

Je pense que la question soulevée, c'est qu'on se sert du for pour rien (et méconnaissance des alternatives) et que c'est synonyme de bad practice, jcrois que le sondage m'appuie, puisqu'il ne s'agit pas de voter un retrait des boucles for (un peu grossier comme exemple) mais plutot de savoir la fréquence d'utilisation des alternatives que chacun fait.

De toute façon, dès qu'on fait un peu de bas niveau, faut dire au revoir à la STL :mrgreen:

Ca n'empêche pas de discuter sur les cas où il ne s'agit pas de performances mais de maintenance/lisibilité

Citation:

---

Envoyé par Bousk

@Michael remy, je n'ai strictement rien compris de tes 2 dernières contributions... 8O

Code:

---

1 2 3

borne=count(mavarialbe) for (a=1;borne<10;a++) {...}

---

il y a plus simple pour réaliser une boucle infinie :aie:
a < borne plutôt non ?
ou ta boucle se charge de décrémenter borne ?
tout cela n'est pas clair

Tous les getSize() de la stl sont const et en temps constants, la "seule perte" c'est l'appel supplémentaire.
Et dans ce cas on privilégiera cette écriture amha

Code:

---

for (int i = 0, t = vec.size(); i < t; ++i) {}

---

---

merci de m'avoir fait remarquer mon erreur ! j'ai corrigé mes exemples !

Citation:

---

Envoyé par JolyLoic

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.

Citation:

---

Envoyé par unBonGars

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:

---

1 2	.L2: jmp .L2

---

C++11 introduit le for_each comme un element du langage, de plus les extensions begin et end fournissent des iterateur autant pour la STL que pour les tableaux et autres zones mémoires allouées par malloc ou new.

Donc à mon sens, il s'agit d'une pratique a enseigner car la STL et les lambda prennent de plus en place....

Ce sont de très bonnes pratiques, mais attention, pour les algos de type "recherche du plus court chemin" par exemple, la library standard complexifie le code en terme de ressources processeur : il est préférable de faire ses propres boucles et structures (expérience personnelle, je suis passé d'une exécution en une journée à 15 secondes...).
Après on peut toujours choisir LA bonne structure standard, mais il y aura à coup sure quelques traitements non prévus... et ça fait mal !

Citation:

---

Envoyé par gbdivers

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

---

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.

Citation:

---

Envoyé par gbdivers

:fleche: Que pensez-vous de cette attitude de supprimer, sauf choix conscient et justifié, les boucles for du code au profit de la STL ?
:fleche: Dans un cadre professionnel, pensez-vous que cette règle soit utile ? Applicable ?

---

Pour que l'idée soit bonne, il faudrait que TOUS les développeurs C++ aient un très bon niveau en STL. Or ce n'est pas le cas. Il y a tous les débutants C++ qui seraient largués avec toutes les fonctions et méthodes standards qu'ils ne connaissent pas, mais aussi les habitués à d'autres librairies (Boost, Qt, librairies de Microsoft par exemple) à qui il manquerait de la pratique de la STL et donc des connaissances dessus.

Prenons l'exemple au stagiaire débutant encore à l'école qui débarque dans l'équipe de développement. Bien sûr, il n'est pas un pro de la STL même si ses cours dessus sont encore relativement frais dans sa tête. Il va passer son temps sur http://www.cplusplus.com à comprendre les algorithmes utilisés dans le code et à chercher ceux qu'il va devoir utiliser puisqu'on lui a proscrit la boucle for. Paye ta productivité !

Je pourrais également citer ma faible expérience en Qt. Elle m'a montré qu'il vaut mieux utiliser les structures de QtCore plutôt que celles de la STL dans un programme Qt (QString au lieu de std::string, QMap au lieu de std::map, etc.). Et ce même s'il existe certaines passerelles entre la "STL standard" et la "STL de Qt" (QtCore). Le problème avec ça, c'est que la STL je ne la pratique pas et je l'oublie.

***

Et puis rien n'empêche de contourner l'interdiction avec un bon vieux while des familles :

Code:

---

1 2 3 4 5

int i = 0; while (i < N) { doSthg(); // Le code de la boucle i++; }

---

:mouarf:

Citation:

---

Il va passer son temps sur http://www.cplusplus.com à comprendre les algorithmes utilisés dans le code et à chercher ceux qu'il va devoir utiliser puisqu'on lui a proscrit la boucle for. Paye ta productivité !

---

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. :mouarf:

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

mais sinon, je suis d'accord avec le bon vieux while, c'est pas joli etc, mais c'est simple et concis.

Citation:

---

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:

---

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

---

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

Code:

---

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

Citation:

---

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