IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Utilisez-vous les algorithmes de la STL en 2012 ?

Votants
114. Vous ne pouvez pas participer à ce sondage.
  • Jamais, je les connais pas.

    26 22,81%
  • Jamais, je les aime pas.

    3 2,63%
  • Exceptionnellement.

    16 14,04%
  • Occasionnellement.

    31 27,19%
  • Les plus souvent possible.

    39 34,21%
  • Toujours.

    3 2,63%
  • Toujours à partir de maintenant, je vais appliquer ta règle.

    0 0%
Sondage à choix multiple
C++ Discussion :

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


Sujet :

C++

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 644
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 644
    Par défaut
    Citation Envoyé par galerien69 Voir le message
    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  2. #2
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    Mars 2004
    Messages
    10 035
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2004
    Messages : 10 035
    Par défaut
    Citation Envoyé par koala01 Voir le message
    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.

  3. #3
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par air-dex Voir le message
    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

  4. #4
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 5 463
    Par défaut
    Citation Envoyé par fcharton Voir le message
    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);
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  5. #5
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par JolyLoic Voir le message
    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
    Dernière modification par Invité ; 03/04/2012 à 11h36.

  6. #6
    Membre Expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Par défaut
    - racourcis
    - donner un nom a l'action
    - pas de bug dans l'implémentation (de la boucle)

  7. #7
    Membre extrêmement actif Avatar de air-dex
    Homme Profil pro
    Inscrit en
    Août 2010
    Messages
    1 706
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France

    Informations forums :
    Inscription : Août 2010
    Messages : 1 706
    Par défaut
    Citation Envoyé par galerien69 Voir le message
    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.

    Citation Envoyé par galerien69 Voir le message
    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.

    Citation Envoyé par fcharton Voir le message
    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".

  8. #8
    Inactif  


    Homme Profil pro
    Inscrit en
    Novembre 2008
    Messages
    5 288
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Secteur : Santé

    Informations forums :
    Inscription : Novembre 2008
    Messages : 5 288
    Par défaut
    Citation Envoyé par air-dex Voir le message
    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

  9. #9
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par air-dex Voir le message
    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.

    Citation Envoyé par gbdivers Voir le message
    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

  10. #10
    Membre confirmé
    Homme Profil pro
    Développeur Web
    Inscrit en
    Mai 2011
    Messages
    66
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Madagascar

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mai 2011
    Messages : 66
    Par défaut
    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.

  11. #11
    Membre éclairé

    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Février 2005
    Messages
    464
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : Industrie

    Informations forums :
    Inscription : Février 2005
    Messages : 464
    Par défaut
    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

  12. #12
    Membre actif
    Inscrit en
    Octobre 2004
    Messages
    83
    Détails du profil
    Informations forums :
    Inscription : Octobre 2004
    Messages : 83
    Par défaut
    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

  13. #13
    Membre actif
    Homme Profil pro
    Inscrit en
    Décembre 2010
    Messages
    49
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : Décembre 2010
    Messages : 49
    Par défaut
    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.

  14. #14
    Membre très actif
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    157
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 157
    Par défaut
    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 ?

  15. #15
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 5 463
    Par défaut
    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.
    Citation Envoyé par singman Voir le message
    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.
    Citation Envoyé par singman Voir le message
    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;
    	}
    }
    Citation Envoyé par singman Voir le message
    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.
    Citation Envoyé par singman Voir le message
    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.

    Citation Envoyé par singman Voir le message
    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.
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  16. #16
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 147
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 147
    Billets dans le blog
    4
    Par défaut
    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.
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  17. #17
    Membre émérite

    Profil pro
    Inscrit en
    Décembre 2008
    Messages
    533
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2008
    Messages : 533
    Par défaut
    Citation Envoyé par Bousk Voir le message
    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.

  18. #18
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 147
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 147
    Billets dans le blog
    4
    Par défaut
    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 )
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

  19. #19
    Membre émérite

    Profil pro
    Inscrit en
    Décembre 2008
    Messages
    533
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2008
    Messages : 533
    Par défaut
    Dans ce cas-là on s'intéressera plutôt à std::accumulate avec std::plus<int>() comme BinaryOp.

  20. #20
    Membre éclairé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2006
    Messages
    519
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Septembre 2006
    Messages : 519
    Par défaut
    Citation Envoyé par Bousk Voir le message
    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;
    }

    Mais de toute façon, cob59 a raison quand il parle de std::accumulate.

Discussions similaires

  1. Réponses: 5
    Dernier message: 20/10/2005, 10h42
  2. [Turbo C++] Fonciton containing for are not expanded inline
    Par BuG dans le forum Autres éditeurs
    Réponses: 6
    Dernier message: 17/02/2003, 06h48
  3. [VB6] For Each ... In ...
    Par Troopers dans le forum VB 6 et antérieur
    Réponses: 3
    Dernier message: 03/02/2003, 12h56
  4. Ce qu'il faut sous la main.
    Par ShinMei dans le forum DirectX
    Réponses: 2
    Dernier message: 18/01/2003, 14h12

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo