Partage
  • Partager sur Facebook
  • Partager sur Twitter

Iterators

Sujet résolu
    21 novembre 2017 à 23:39:27

    Bonsoir bonsoir,

    Voilà j'écrivais une fonction pour manipuler un peu les iterators sur une liste et pour le fun aussi. Cette fonction est simple, elle s'occupe de vérifier si l'élément d'une liste vaut 0 et si c'est le cas, on lui assigne la valeur de l'élément précedent + 1. Sauf dans le cas ou c'est le tout premier élément qui est égal à 0, dans ce cas on lui assigne 1 tout simplement.

    C'est fonctionnel mais quelque chose m'échappe au moment d'assigner la nouvelle valeur, je m'attendais à ce que la décrémentation agisse aussi sur le "left-operand" *beg_lst (et donc que cela foire) mais non ça fonctionne :

    void reload_list(std::list<int>& lst)
    {
        auto beg_lst = lst.begin();
        auto end_lst = lst.end();
    
        while(beg_lst != end_lst){
            if(*beg_lst == 0){
                if(beg_lst == lst.begin()){
                    *beg_lst = 1;
                }else{
                    *beg_lst = *--beg_lst+1; // OK mais ??
                    ++beg_lst;
                }
            }
            ++beg_lst;
        }
    }
    
    ///// MAIN /////
    int main()
    {
        std::list<int> lst{0, 0, 3, 0, 5, 0, 7, 0, 9, 0};
        reload_list(lst); // Ok : 1 2 3 4 5 6 7 8 9 10
    
        return 0;
    }


    Si éventuellement, explications sur le pourquoi du comment il y a, je suis preneur ^^

    Par avance, merci.

    -
    Edité par Guit0Xx 21 novembre 2017 à 23:45:45

    • Partager sur Facebook
    • Partager sur Twitter

    ...

      22 novembre 2017 à 0:08:38

      Pas compris ta question, mais regarde la priorité des opérateurs.

      Par contre, ca : "*--beg_lst+1", c'est de la merde. Ca sert a rien de prendre le risque de se tromper sur l'ordre des opérateurs, alors qu'il suffit de mettre des parenthèses ou de créer des variables intermédiaires pour éviter l’ambiguïté.

      HS :

      - pourquoi reference non constante ?

      - pourquoi list et pas vector ? (sauf besoin specifique, evites std::list)

      - le mieux est d'utiliser la meme signature que les algos de la lib standard

      template<typename Iterator>
      void reload_list(Iterator first, Iterator last)

      - quel est l'interet de rendre le code moins lisible en raccourcissant les noms ? (beg au lieu de begin, lst au lieu de list)

      -
      Edité par gbdivers 22 novembre 2017 à 0:11:49

      • Partager sur Facebook
      • Partager sur Twitter
        22 novembre 2017 à 0:20:25

        gbdivers a écrit:

        Pas compris ta question, mais regarde la priorité des opérateurs.

        Ça marche, j'irai faire un tour de ce côté.

        gbdivers a écrit:

        Par contre, ca : "*--beg_lst+1", c'est de la merde.

        Oui je trouve ça crade aussi, j'essayais de réduire au maximum. À la base c'était comme ça:

        --beg_lst;
        const int new_val{(*beg_lst)+1};
        ++beg_lst;
        *beg_lst = new_val;
        

        gbdivers a écrit:

        - pourquoi reference non constante ?

        Parce que la fonction peut être amenée à modifier certains éléments de la liste.

        gbdivers a écrit:

        - pourquoi list et pas vector ? (sauf besoin specifique, evites std::list)

        Tout simplement parce que j'voulais voir un peu les listes, et que ce code n'a aucun but précis, c'est de l'amusement. Et ne t'en fais pas, j'affectionne beaucoup les vector :)

        gbdivers a écrit:

        - le mieux est d'utiliser la meme signature que les algos de la lib standard

        template<typename Iterator>
        void reload_list(Iterator first, Iterator last)

        Yep, mais avant ça, j'compte bien étudier un peu plus les iterators et les templates avant de manipuler le tout.

        gbdivers a écrit:

        - quel est l'interet de rendre le code moins lisible en raccourcissant les noms ? (beg au lieu de begin, lst au lieu de list)

        Parce qu'il est tard :). Mais pas de souci, je m'applique quand je code sérieusement. Là c'est juste un truc perso sans importance.

        -
        Edité par Guit0Xx 22 novembre 2017 à 1:34:04

        • Partager sur Facebook
        • Partager sur Twitter

        ...

          22 novembre 2017 à 0:27:29

          Justement, c'est ta reduction qui est caca
          • Partager sur Facebook
          • Partager sur Twitter
            22 novembre 2017 à 0:31:47

            gbdivers a écrit:

            Justement, c'est ta reduction qui est caca


            Ok je note : trop de réduction = caca :D
            • Partager sur Facebook
            • Partager sur Twitter

            ...

              22 novembre 2017 à 4:35:36

              Salut,

              Guit0Xx a écrit:

              Parce qu'il est tard :). Mais pas de souci, je m'applique quand je code sérieusement. Là c'est juste un truc perso sans importance.

              Justement, il faut comprendre que ce sont tous ces trucs "sans importance" que tu fais à gauche et à droite quand tu débutes qui font la base de ce qui sera tes habitudes personnelles par la suite.

              Surtout les choses qui auront fonctionné alors que tu ne t'y attendais peut-être pas !

              La raison est simple: Les deux choses que l'on retient le plus facilement sont l'expérience personnelle et les choses qui nous font réagir.  Et, si c'est une expérience personnelle qui nous fait réagir -- par exemple, parce que l'on est surpris du résultat -- on a vraiment toutes les chances de s'en souvenir...

              Et à partir de là, les choses vont forcément s'enchaîner:  comme on se souviendra de cette expérience personnelle, on aura régulièrement tendance à se dire "mais au fait, ca marchait si bien comme cela", et donc, à reproduirele même "schéma de pensée".

              Et, à force de reproduire ce même schéma de pensée, il deviendra une habitude: quelque chose que l'on arrive à faire "les yeux fermés"; sans même avoir à y réfléchir.

              Alors, cela n'a l'air de rien, mais, si lors de tes essais tu décides d'écrire beg au lieu de begin, lst au lieu de list, attckNemi au lieu de attackEnnemi, ..., tu prendra l'habitude de réduire les noms.  Parce que ca marche!  Et tu perdras de vue le fait que ton code doit être lisible.  Parce qu'il te semble (sur le moment même en tout cas) parfaitement lisible!

              Et il n'y aura vraiment que si tu décide de revenir sur ce code "jetable" plusieurs mois plus tard que tu te rendras compte qu'en fait, il n'était pas si lisible que cela!  Mais, entre temps, l'habitude aura été prise...

              • Partager sur Facebook
              • Partager sur Twitter
              Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs  à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
                22 novembre 2017 à 12:42:02

                Je vois très bien où tu veux en venir, je sais pertinemment que choisir des noms de variable est quelque chose de très important. Mais là sur du code "éphémère" aussi court dont je ne garderai aucune trace, sincèrement ce n'est pas ma priorité.

                En revanche, lorsqu'il s'agit d'un projet à long terme ou même d'un bout de code que je souhaite conserver, tu peux être certains que je vais mettre le paquet niveau clarté. Je viens d'ailleurs de faire l'expérience avec un projet qui est en veille depuis 2 mois, et bien je peux t'assurer que je n'ai pas lésiné sur la clarté des noms. Quitte à mettre des noms à rallonge tant que c'est le plus compréhensible possible (aussi bien pour moi que pour un éventuel lecteur).

                En tous cas, je ferai des efforts sur les noms de variables la prochaine fois que je partagerai un bout de code avec vous c'est promis ^^

                -
                Edité par Guit0Xx 22 novembre 2017 à 12:57:19

                • Partager sur Facebook
                • Partager sur Twitter

                ...

                  24 novembre 2017 à 0:01:45

                  Finalement vous aviez raison @koala et @gbdivers pour les noms de variables réduis :p.

                  Tout à l'heure j'ai entamé un petit projet et en écrivant une fonction j'ai instinctivement utilisé des abréviations par pur réflèxe. Résultat, j'ai été contraint de renommer l'intégralité des variables pour être sûr de m'y retrouver par la suite ^^.

                  J'appliquerai ce conseil à la lettre dorénavant (même pour du code sans importance), histoire d'éliminer cette mauvaise habitude.

                  Merci ;)

                  -
                  Edité par Guit0Xx 24 novembre 2017 à 0:59:47

                  • Partager sur Facebook
                  • Partager sur Twitter

                  ...

                    24 novembre 2017 à 9:46:45

                    C'est très honnête à toi de le reconnaitre :D

                    Comme quoi, tu vois, je suis peut-être un vieux con chiant qui s'attarde sur des problèmes qui ne semblent pas en être, mais je suis un vieux con chiant qui sait de quoi il parle :D

                    • Partager sur Facebook
                    • Partager sur Twitter
                    Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs  à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait

                    Iterators

                    × Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
                    × Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
                    • Editeur
                    • Markdown