Discussion :

[JolyLoic]

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

[rhludovic]

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.

[Invité]

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]

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

[bizulk]

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

[JolyLoic]

Pour la différence entre for_each avec et sans lambdas, c'est juste en effet un raccourci d'écriture, mais ce raccourci permet aussi autre chose qui est important, c'est la localité du code. Le contenu de la boucle est défini là où il est utile, et non pas comme tu commentais toi même dans ton post précédent :
(ailleurs dans le code, généralement loin)

Pour le range based for loop, l'intérêt est plus qu'un simple raccourci par rapport au for classique :
- C'est effectivement plus court
- Pas de risque de mettre des itérateurs qui ne forment pas de range
- On sait au premier coup d'oeil qu'on va itérer une fois et une seule sur les éléments du conteneur, sans devoir lire le contenu de la boucle, car la variable d'itération n'est pas exposée.

[Invité]

- On sait au premier coup d'oeil qu'on va itérer une fois et une seule sur les éléments du conteneur, sans devoir lire le contenu de la boucle, car la variable d'itération n'est pas exposée.

Ah oui mais non...

D'abord, on expose la variable d'itération (i ici)

Code :

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

for(int i : v) ...

Ensuite, on est dans un pur raccourci:

Code :

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

for(int i : v) === for(int i=0;i<v.size();i++)

(ou toute version équivalente utilisant std::distance())

Enfin, on part du principe que LA BONNE itération sur un conteneur, c'est l'itération sur TOUT le conteneur. C'est une très mauvaise idée, à mon avis. La plupart des "bons" algorithmes sur conteneur reposent justement sur l'idée qu'on peut itérer sur de petits morceaux de celui ci (c'est le principe du diviser pour régner).

Au final, c'est un raccourci et un pousse au crime. Je pense que ca part d'une de ces bonnes intentions dont l'enfer est pavé: ouvrir le C++ aux informaticiens fâchés avec l'algorithmique (ceux qu'on reconnait en entretien parce qu'ils expliquent qu'ils programment depuis l'âge de six ans...), mais ca n'en reste pas moins une mauvaise idée (ou, tout au plus, un raccourci d'écriture sans grande importance).


Pour un exemple de boucle sans variable d'itération, je te conseille de regarder des langage "orientés tableaux" comme l'APL, le K ou le J. Un petit exemple: en J, la moyenne s'écrit "+/ % #" (somme (+/) divisé par (%) nombre (#))

+/ 1 2 3 = 6
1 % 2 = 0.5
# 1 2 3 = 3

+/ % # 1 2 3 = 2

(un vieux fil sur le J, pour ceux que ca intéresse
http://www.developpez.net/forums/d86...s-pratiquants/
)

Francois

[yan]

L'habitude d'utiliser des algo permet(ra?) aussi la manipulation haut niveau des threads. De plus en plus d'outil propose des algo concurrent :

QtConcurrent
tbb
gcc
...


Y as bien OpenMP pour les boucle for. Mais ça reste du bas niveau.

[Klaim]

Ensuite, on est dans un pur raccourci:

Code :

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

for(int i : v) === for(int i=0;i<v.size();i++)

(ou toute version équivalente utilisant std::distance())

Dites moi si je me trompe, mais ces deux exemples ne correspondent pas du tout.

En fait:

Code :

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

for(int i : v) mon_code();

equivaut à

Code :

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

1
2
3
4
5
for(auto it=begin(v); it != end(v); ++it)
{ 
     int i =*it;
     mon_code();
}

C'est à dire que la variable exposée n'est justement pas l'itérateur mais bien le nom de l'élément qui correspondra à chaque élément itéré dans la boucle.
De la même manière:

Code :

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

for(const auto& k : c) mon_code( k );

équivaut à

Code :

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

1
2
3
4
5
for(auto it=begin(c); it != end(c); ++it)
{ 
     const auto& k =*it;
     mon_code( k );
}

(c'est d'ailleurs un pattern que je vois partout dans mon code C++03 et qui à sauté dans la plupart de mon code c++11)

Autrement dit, une autre différence avec for_each est qu'on ne peut pas préciser le range sur lequel on veut travailler avec un for(:). On travaille toujours sur un container complet. Ou sur un objet range.

De plus, mon_code() (si on le remplace par du code dans ce bloc) pourrait très bien être du code qui fait un break ou un continue tandis qu'avec for_each on sait que c'est juste impossible.

Le for(:) n'expose jamais les itérateurs. Je crois d'ailleurs qu'il n'y a aucun moyen de les utiliser. Même chose avec un for_each, le foncteur en paramètre (généré par un lambda, de préférence) ne peut pas accéder à l'itérateur.

Or il y a des tas de cas ou on a besoin de cet itérateur. L'utilité des boucles for habituelles est donc difficile à renier.

[Joel F]

L'habitude d'utiliser des algo permet(ra?) aussi la manipulation haut niveau des threads. De plus en plus d'outil propose des algo concurrent :

QtConcurrent
tbb
gcc
...


Y as bien OpenMP pour les boucle for. Mais ça reste du bas niveau.

et encore mieux, avec des IteratorAdaptor ou des RangeAdaptor, tu fait le café. C'est le systeme qu'on a pris pour Boost.SIMD ou vectoriser un algo sur un conteneur contigu se resume a adapte son begin()/end().

[yan]

C'est le systeme qu'on a pris pour Boost.SIMD

Ca fait déjà partie de boost? ou c'est en cours de finalisation?

[gbdivers]

Hors-sujet :

Ca fait déjà partie de boost? ou c'est en cours de finalisation?

Pas encore mais tu peux le télécharger dans NT2

@JoelF
A quand un tuto sur boost.simd ?

[Matthieu Brucher]

Vous bossez tous les deux pour la même boîte ? (Joël et gbdivers).

Potentiellement intéressant, le Boost.SIMD...

[gbdivers]

Non. Je suis comme toi, je suis potentiellement intéressé par boost.simd donc je suis l'évolution du projet.
Pour moi, boost.simd et les algorithmes sont des exemples d'un des points forts du C++ : offrir la possibilités de manipuler des concepts de (plus ou moins) haut-niveau sans surcoût grâce aux templates.

S'en priver, c'est voir le C++ que comme un langage bas niveau et perdre ce qui fait que le C++ est un langage productif. Je suis donc surpris que certains puissent penser que réécrire les algorithmes est plus productif que d'utiliser l'existant (en comptant les tests, la maintenance et l'évolutivité)

[JolyLoic]

Dites moi si je me trompe, mais ces deux exemples ne correspondent pas du tout.

Je suis d'accord, j'allais répondre la même chose. J'ai repris l'exemple initial, mais c'est clair que le fait que dans un cas on itère avec un entier et dans l'autre on itère sur un vecteur d'entier n'aidait pas à clarifier...

Le for(:) n'expose jamais les itérateurs. Je crois d'ailleurs qu'il n'y a aucun moyen de les utiliser. Même chose avec un for_each, le foncteur en paramètre (généré par un lambda, de préférence) ne peut pas accéder à l'itérateur.

Or il y a des tas de cas ou on a besoin de cet itérateur. L'utilité des boucles for habituelles est donc difficile à renier.

Cette non-exposition est à la fois un avantage et un inconvénient. Un avantage car il permet de s'assurer d'un seul coup d’œil que l'on est dans le cas le plus courant d'un simple parcours. Un inconvénient car il n'est pas adapté à l'ensemble des cas possibles.

[Invité]

Dites moi si je me trompe, mais ces deux exemples ne correspondent pas du tout.

Ca dépend de ce que tu mets après...
Mon exemple d'origine disait

Code :

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

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

celui de JolyLoic est

Code :

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

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

Ils ne me semblent pas si différents que cela. Dans les deux cas, la variable d'itération est muette, et ce qu'on passe à fait_qqch() c'est bien l'élément sur lequel on itère.

Francois

[air-dex]

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.

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.

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]

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é]

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.

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

[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