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 :
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
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
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...
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
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
Finalement vous aviez raison @koala et @gbdivers pour les noms de variables réduis .
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.
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
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.
...
Discord NaN. Mon site.
...
Discord NaN. Mon site.
...
...
...