Bonjour, désolée je sais que je devais plus poster des trucs mais là c'est très important.
Quand on fait les choses de telle ou telle manière, il faut d'abord s'assurer que cette méthode apporte des bénéfices concrets. Par exemple pour la différence entre une classe à sémantique de valeur ou d'entité, ok on peut considérer que cette sémantique existe mais à un moment donné il faut se demander si ça permet vraiment d'aller plus loin dans le projet, atteindre de meilleurs résultats, etc. On s'en fout de compliquer la structure du code si au final ça ne permet pas de le rendre plus facile à maintenir etc. Il y a déjà suffisamment de problèmes à résoudre sans en plus se poser des questions qui n'apportent pas forcément quelque chose. Il ne suffit pas de trouver tel ou tel concept et de se dire qu'on va le mettre partout, il faut aussi se demander ce que ça va apporter.
Et ça vaut aussi quand Casey dit qu'un truc est nul, il le dit lui même dans cet extrait qu'il faut évaluer soi même les bénéfices par rapport aux coûts (par exemple des templates à droite à gauche ça veut dire du temps de compilation en plus, etc, il y a toujours des coûts) et pas se contenter de suivre ce qu'un oncle a dit, qui ne s'applique pas forcément à notre projet
Le problème est que Casey est un con arrogant incompétent en C++ et qu'il dit beaucoup de caca. Du coup, toute discussion basée sur "Casey a dit..." sera aussi du caca. (Tu veux que je ressorte toutes les fois où j'ai pris le temps de regarder les liens que tu avais donné sur Casey et que j'expliquais en quoi il disait du caca ?)
> il faut aussi se demander ce que ça va apporter.
Virer copiabilité d'une classe qui correspondait complètement à une entité m'aurait évité de perdre 3 mois à implémenter un truc excessivement complexe et qui n'a jamais servi...
Dommage, personne n'en parlait encore à l'époque... On se demande bien du coup d'où ces conseils de conception peuvent bien venir...
Ce n'est pas parce que tu n'en as pas encore perçu les implications pour t'être pris ce mur dans la figure ou que ton dieu du C++-mais-pas-trop-plus n'a abordé le soucis qu'il n'existe pas. La simplicité c'est aussi un truc que l'on va atteindre quand on sait reconnaitre quand il y a des choses qui vont compliquer le désign. Et si en plus, il y a une heuristique simplificatrice, bingo. On gagne du temps à l'écriture, en encore plus en maintenance justement.
EDIT: ça me rappelle ce billet de blog d'un Javaiste qui disait en substance: "OSEF le LSP". Ah ah. Ca me fait rire à chaque fois. S'il y a bien un truc qui est mortel et non solutionnable, c'est ça. Si en plus on y rajoute la copie (ou le déplacement), double-pouf!
EDIT2: J'imagine qu'il faut avoir fait pompier sur des projets de plusieurs dizaines de personnes pour comprendre l'intérêt de faire les choses bien...
Pour ma part, je ne connais pas Casey, j'ai pas pris le temps d'aller voir ses documents ou ses vidéos. C'est surement très intéressant mais je n'ai pas pris le temps.
Moi ce qui me gène, c'est le "Casey a dit que". ça me rappelle quand parfois sur le net, certains parlent religion. Un moment on argumente un peu et la discussion finit toujours par "C'est écrit dans le Coran donc c'est tout", ou bien "C'est Dieu qui l'a dit donc c'est tout"
Il est certainement très fort, je n'en doute pas. Mais je ne suis pas sûr qu'il existe un programmeur sur cette planète qui connaisse tout sur tout à la perfection sur ce qu'il faut faire dans toutes les situations.
Donc moi j'aurais plutôt tendance à demander sur quel problème concret as tu une divergence avec les gens qui forums, et que Casey ne fait pas pareil ?
> il faut aussi se demander ce que ça va apporter.
Virer copiabilité d'une classe qui correspondait complètement à une entité m'aurait évité de perdre 3 mois à implémenter un truc excessivement complexe et qui n'a jamais servi...
De quoi s'agissait-il exactement ? Si ça n'avait pas de sens de copier la classe, pourquoi avoir voulu le faire ? Par exemple j'ai pas l'idée de retourner l'écran et coder à l'envers, ce n'est pas la peine de mettre une règle à ce niveau là puisque ça n'a pas de sens (sans mauvais jeu de mot). Et si on veut faire des Cercle et des Ellipse, au lieu de se dire "tiens un cercle c'est une ellipse on va mettre un héritage" puis ensuite se rendre compte que ça viole le LSP, il suffisait de se rendre compte qu'un cercle c'est une position et un rayon et une ellipse c'est une position et deux rayons et donc que l'héritage ne fonctionne pas, pas besoin de LSP pour s'en rendre compte.
Fvirtman a écrit:
Donc moi j'aurais plutôt tendance à demander sur quel problème concret as tu une divergence avec les gens qui forums, et que Casey ne fait pas pareil ?
En regardant des trucs par ci par là je suis tombée sur un livre de Philippe Dunski que vous connaissez sans doute (https://www.d-booker.fr/programmation-et-langage/157-coder-efficacement.html) dans lequel il implémente un jeu d'échec (https://github.com/D-BookeR/Livre-Coder-efficacement). Il y a beaucoup de petits détails qui ne me plaisent pas (y compris des choses qui ne VOUS plaisent pas, genre `~Foo::Foo {}` ou `assert(color == colorWhite || color == colorBlack)` alors que si color était une enum class ça serait imposé à la compilation, ou encore des fonctions qui renvoient des pointeurs nus (ok ça peut passer), mais là ça renvoie le retour de new !!!!) et je trouve que le code est globalement difficile à lire, avec beaucoup de "bruit" genre des fonctions qui sont juste là pour renvoyer false (ce qui n'apporte pas grand chose dans la résolution du problème original, vous en conviendrez), et la plupart des fichiers ne contiennent aucune logique, difficile donc de savoir ce qui se passe.
> De quoi s'agissait-il exactement ? Si ça n'avait pas de sens de copier la classe, pourquoi avoir voulu le faire ?
Parce qu'il y a vingts cinq ans, on apprenait dans tous les cours que pour une nouvelle classe il fallait définir le constructeur par défaut, le destructeur, le constructeur par copie et l'opérateur d'affectation (comme ceux qui apprennent toujours aujourd'hui en OO, qu'il faut définir getters et setters pour tout attributs). Autant dire que j'avais pas plus de recul que les cours qui me tombaient sous la main. Et j'étais loin dans le seul.
Sinon, il s'agissait d'un réseau de neurones artificiels où j'avais eu la saugrenue idée de modéliser chaque neurone indépendamment => un foutoir de pointeurs dans tous les sens. Rajoute peu d'expérience à l'époque, ça prend du temps à faire correctement. Techniquement, la copie est faisable, pourquoi s'en priver. D'autant qu'il y avait bien un destructeur et que la Rule of Big Four était claire: il fallait vraiment définir les 2 opérations de copie dans ce cas. Qu'il y avait toujours le risque d'un utilisateur qui prend le paramètre par valeur. Sauf que techniquement un RdNA qui vit sa vie (apprend, et ensuite traite), c'est une entité. Aucun sens de s'intéresser à la comparaison, aucune raison de dupliquer.
C'est comme les désign patterns, le concept de "ce machin n'a aucun intérêt à être copié", ça s'appelle probablement une entité. On donne un nom qui résume un ensemble de propriétés, de conséquences, et de comment cela se traduit en code. Le pouvoir de donner des noms pour mieux communiquer.
> Et si on veut faire des Cercle et des Ellipse, au lieu de se dire "tiens un cercle c'est une ellipse on va mettre un héritage" puis ensuite se rendre compte que ça viole le LSP, il suffisait de se rendre compte qu'un cercle c'est une position et un rayon et une ellipse c'est une position et deux rayons et donc que l'héritage ne fonctionne pas, pas besoin de LSP pour s'en rendre compte.
Tu es encore naïve. Passons que cet exemple est volontairement choquant car allant à l'encontre de ce que l'on apprend au collège, et plus, sur des objets mathématiques dépourvus de comportements.
Il ne manque pas d'exemples de cas de modélisation qui violent le LSP: SortedList qui dérive de List (Java 1.0 -- et il y a encore il me semble des héritages entre des dates de précisions différentes, cf. Effective Java de Joshua Blooch), PointColoré qui dérive de Point (toujours 99.999% des cours qui enseignent l'OO). Le LSP n'est qu'un outil, un marteau, qui démontre par l'absurde ce qu'une intuition pourra nous dire est faux ou juste à 100%. Parfois c'est bien d'avoir des preuves certaines que quelque chose est bien, ou au contraire dangereux.
Si on s'en éloigne, on prend alors le risque qu'en cas de mélanges de uses cases initialement distincts, alors plus rien ne peut marcher ensemble. Pourquoi est-ce que je pense à cette idée de boire de la javel pour soigner du covid... Je réfléchirai si c'est réfutable par LSP.
> genre `~Foo::Foo {}`
Parce que le détail m'a échappé à la relecture, et qu'à l'époque je ne savais pas encore qu'il y avait un véritable intérêt à utiliser "= default".
> assert(color == colorWhite || color == colorBlack)` alors que si color était une enum class ça serait imposé à la compilation
Malheureusement non car les castings restent possibles. Mais je ne sais plus pourquoi on n'était pas partis sur les enum class à la relecture.
Je laisse Philippe répondre pour les critiques relativement au désign.
Mais attention de ne pas t'emballer. J'ai peur de ce que tu cherches à démontrer. On ne loue aucun culte à aucun d'entre nous. Et nous ne demandons aucun sacrifice en nos noms non plus! On a des opinions appuyées (théories) ou non (intuitions), elles changent au fil des années, on n'est pas toujours d'accord entre nous non plus. Et ce qui importe n'est pas qui dit, mais ce qui est dit.
PierrotLeFou a écrit:
Et si un cercle était une ellipse avec les deux foyers confondus?
Comme d'hab. Que devient le cercle du moment où tu changes la position d'un des foyers? Les définitions mathématiques de ces objets concernent des objets immuables. Dans un système informatique de dessin vectoriel où l'on pourrait imaginer que l'on déplace et déforme ces objets, l'héritage ne marche alors plus.
D'ailleurs je viens de regarder juste le début du stream. Autant j'admets que les conventions ça ne se discute peu car c'est subjectif mais pour le coup je n'ai jamais vu non plus de ma vie des types en underscore_case et les fonctions en PascalCase.
git is great because Linus did it, mercurial is better because he didn't.
Il ne faut pas oublier que le livre a été en 2013 et on avait moins de recul. Et "= default" reste du détail syntaxique.
Surtout, c'est pas un code destiné à être utilisé. C'est un code qui sert à illustrer les concepts expliqués dans le livre. Philippe voulait insister particulièrement sur les principes SOLID dans son livre et son code est volontairement très orienté objet.
Et bien sur que sur un livre destiné aux débutants, le code est volontairement (encore) inutilement très détaillé. C'est un choix pédagogique d'auteur, pas un choix technique de développeur.
Ce sont des choix, criticables (comme n'importe quel choix), qu'il explique dans le livre.
Fvirtman a écrit:
Il est certainement très fort
En réalité, même pas. Il le dit lui même qu'il n'a pas fait de C++ depuis 10-15 ans.
Fvirtman a écrit:
Donc moi j'aurais plutôt tendance à demander sur quel problème concret as tu une divergence avec les gens qui forums, et que Casey ne fait pas pareil ?
Casey pense que le comité C++ sont tous les incompétents qui ne savent pas programmer (c'est pas un résumé exagéré de ma part, c'est ce qu'il dit littéralement) et que tous les devs C++ sont des moutons qui ne font que suivre bêtement les nouveautés du C++ sans comprendre en quoi c'est nul (encore une fois, c'est pas une exagération de ma part).
Perso, je suis pas d'accord avec cette opinion
(Et globalement, Casey pense que tout ceux qui ne sont pas d'accord avec lui sont idiots. D'où mon "con arrogant incompétent en C++" de mon premier message)
On s'en fout... La complexité vient essentiellement de deux points différents:
D'un coté, il y a la complexité intrinsèque, celle qui vient directement du besoin auquel on doit répondre, et de l'autre, la complexité due à des décisions qui n'étaient pas forcément "les meilleures", qui ont amené avec elles plus de problèmes (qu'il faudra résoudre à un moment ou à un autre) que de solutions, et qu'il faut absolument essayer d'éviter au maximum par une conception "correcte".
JadeSalina a écrit:
Si ça n'avait pas de sens de copier la classe, pourquoi avoir voulu le faire ?
Ce n'est pas forcément que l'on a voulu le faire, c'est que c'est la manière de travailler du compilateur dés qu'il s'agit de transmettre un paramètre à une fonction: par défaut, il transmet l'information par copie. Il faut lui préciser que l'on veut utiliser une référence (ou un pointeur) sur cette donnée pour éviter qu'il n'en fasse la copie.
Il suffit donc d'oublier une esperluette dans le code pour qu'une information (qui aurait pu être) qui n'est pas censée être copiée subisse la copie malgré tout.
JadeSalina a écrit:
Par exemple j'ai pas l'idée de retourner l'écran et coder à l'envers, ce n'est pas la peine de mettre une règle à ce niveau là puisque ça n'a pas de sens (sans mauvais jeu de mot).
Cela n'a rien à voir. Tu prends tes propres décisions quant à la position de ton écran. La copie des donnée est le comportement par défaut du compilateur, qui t'est imposé par celui-ci, et qui respecte en cela ce que l'on appelle la "forme canonique orthodoxe de Coplien" (je te laisse faire tes recherches sur le sujet).
Il se fait que, si la copie n'a aucun sens, tu peux -- effectivement -- dire au compilateur que "cette donnée n'a aucun sens à être copiée". Mais que si tu ne le lui dis pas, il n'a aucune raison de s'inquiéter des copies éventuelles qui seront faites.
Par contre, si tu mets une mécanique en place qui lui interdira explicitement de créer des copies, le compilateur sera "assez malin" que pour respecter cette règle, et pour s'assurer que, quoi qu'il puisse arriver (y compris l'oubli d'une esperluette dans la signature d'une fonction), la copie ne pourra pas être faite.
Scott Meyers nous as sans doute donné le conseil le plus sage que l'on puisse trouver en développement:
Make things (interfaces) easy to use correctly and hard to use incorrectly
(Rendez les choses (les interfaces) faciles à utiliser correctement et difficile à utiliser de manière incorrecte)
Parce que l'on ne sait jamais qui va utiliser le code que l'on a écrit, et dont on oublie bien souvent les détails avec le temps. Parce que l'on doit partir du principe que celui qui va l'utiliser est un "imbécile idiot, qui n'attend qu'une occasion de faire une connerie, qu'il fera en outre quoi qu'il arrive au pire moment qui soit".
Cette description de l'utilisateur est valide pour tous les développeurs. Pour toi, pour moi, pour ceux qui sont beaucoup plus intelligents que moi, pour ceux qui commencent à peine à s'intéresser au développement.
La seule chose, c'est que l'erreur qui sera commise par les personnes "les plus qualifiées" seront aussi très souvent les erreurs les plus difficiles à retrouver et à corriger. Plus on devient qualifié, plus les erreurs deviennent subtiles, complexes et ... problématiques.
Et c'est pour cela que, si tu peux faire en sorte de rendre ta chose "impossible" à utiliser de manière incorrecte, il faut vraiment penser à le faire.
Et comment donc, les gens connaissent. Et pour cause ... Car c'est moi, Philippe Dunski
JadeSalina a écrit:
Il y a beaucoup de petits détails qui ne me plaisent pas (y compris des choses qui ne VOUS plaisent pas, genre `~Foo::Foo {}`
Hé bien, si tu profitais de la présence de l'auteur pour lui poser les questions qui te trottent en tête?
Et dis moi, qu'est ce qui te chagrine dans le fait que j'ai fourni une implémentation (vide) du destructeur d'une classe au lieu de le marquer =default?
Dis toi que ce n'est de toutes manière "qu'un détail d'implémentation" ;). Et qu'en plus, si je l'ai fait, c'était pour une excellente raison au moment où le code a été écrit :
Il se fait que ce livre a été rédigé en septembre 2013, relu pendant quatre mois, et qu'il est paru dans les kiosques en février 2014. A l'époque, la norme C++11 est sortie depuis deux ans, et elle est "globalement" respectée par la plupart des compilateurs.
Sauf en ce qui concerne MSVC (le compilateur de chez microsoft), qui est dans sa version 2012, et qui -- juste pour faire chier tout le monde -- est le seul compilateur à ne pas supporter (entre autre) l'indication =delete.
Comme je ne pouvais pas présumer du compilateur qui serait utilisé, j'ai donc du me résoudre à ne pas utiliser l'ensemble des possibilités qui étaient offertes par la nouvelle norme. Et c'est comme cela que l'on retrouve, dans un code qui date de 2013, encore des "relents" de pratiques "anciennes"
JadeSalina a écrit:
ou`assert(color == colorWhite || color == colorBlack)` alors que si color était une enum class ça serait imposé à la compilation,
Tu as raison, une enum class aurait tellement bien fait l'affaire. C'était sans compter la version de MSVC que j'ai utilisé pour m'assurer que le code compilait avec l'ensemble des compilateurs à ma disposition (Gcc, Msvc, et clang, sur différents systèmes), qui me lançait une erreur de compilation lorsque j'essayais d'utiliser cette fonctionnalité pourtant géniale.
Encore une fois, j'ai du prendre une décision pour que les choses se passent "pour le mieux" dans toutes les circonstances
Note au passage que l'assert a de toutes manière largement sa place, car l'énumération (aurait-elle été une enum class, cela n'aurait rien changé ) contient quatre valeurs distinctes:
noColor (l'absence de couleurs), utilisée pour la mise en place d'un "null object" : un objet qui est forcément invalide quoi qu'il arrive,
colorWhite qui permet de représenter les pièces de couleur blanche
colorBlack qui permet de représenter les pièces de couleur noire
colorMax qui permet d'avoir une valeur numérique entière (vu qu'il s'agit d'une valeur énumérée) équivalent au nombre maximal de valeur énumérées. Très utile lorsque l'on souhaites définir un tableau contenant un nombre d'élément exactement égal au nombre de valeurs énumérées
Les commentaires de génération de documentation indiquent d'ailleurs très clairement la raison pour laquelle chacune de ces valeurs est définies. Et on retrouve d'ailleurs une explication de la manière dont ces valeurs énumérées sont utilisées dans les différents commentaires de génération de documentation que l'on retrouve tout au long du projet.
Car, lorsque tu crées quelque chose, il faut te dire que cela ne sera utile que si cette quelque chose est utilisée, et que la manière dont tu prévois qu'elle sera utilisée est justement ce qui va la rendre utile... A condition qu'elle soit ... correctement utilisée.
J'ai donc quatre valeurs énumérées, que j'aurais également eues si j'avais (pu) utiliser les enum class. Mais je n'ai que deux valeurs sur quatre qui permettent effectivement de représenter une pièce "valide". L'assertion a donc parfaitement sa place pour s'assurer que la pièce que j'essaie de manipuler soit effectivement valide.
Et comme il s'agit d'une assertion, j'ai la certitude que toute personne essayant de me transmettre une pièce invalide se fera engueuler lors des tests. Rendre les choses difficiles (voire impossibles) à utiliser de manière incorrectes, disions nous?
JadeSalina a écrit:
ou encore des fonctions qui renvoient des pointeurs nus (ok ça peut passer), mais là ça renvoie le retour de new !!!!)
Oui, et alors? la fonction make_unique n'existait pas à l'époque, et cette fonction qui renvoiie un pointeur pour lequel la mémoire a été allouée avec new n'est utilisée que dans un contexte bien particulier: la mise en place des pièces sur l'échiquier.
Ce contexte est suffisamment précis et suffisamment "maitrisé" que pour que cela ne pose pas de problème particulier à le faire, d'autant plus que ce contexte va faire faire prendre nos pointeurs nus en charge par des unique_ptr.
Encore une fois, j'ai du prendre des décisions, elles peuvent être remises en cause aujourd'hui, soit huit ans après la sortie du livre, mais elles étaient toutes murement réfléchies lorsque que je les ai prises, et je savais exactement pourquoi je les prenais
JadeSalina a écrit:
et je trouve que le code est globalement difficile à lire, avec beaucoup de "bruit" genre des fonctions qui sont juste là pour renvoyer false (ce qui n'apporte pas grand chose dans la résolution du problème original, vous en conviendrez)
C'est parce que tu manques, encore une fois, cruellement de recul pour pouvoir juger. Mais ne t'en fais pas, ce recul viendra avec l'expérience :
Tu vois une fonction -- dont tu n'as même pas encore fait attention au nom, qui renvoie false, et tu pars du principe que... ca ne sert à rien. Pour être honnête, s'il n'y avait que cette fonction prise hors de tout contexte, ta réaction "épidermique" pourrait presque se justifier. C'est là que le recul commence à devenir intéressant.
Car, si tu pars du principe que cette fonction n'apporte rien, tu en viendras avec un peu d'habitude à te dire que si "quelqu'un" -- qui n'est a priori pas plus bête que toi, et qui a sans doute plus l'habitude que toi, et qui est certainement au moins aussi paresseux que toi -- a jugé utile d'écrire un code que tu n'aurais a priori pas écrit, c'est qu'il y a quand même sans doute "une bonne raison" pour le faire. Et ce, même si cette raison ne te saute pas directement aux yeux.
Car celui qui a écrit le code, il sera sans doute parti, comme toi, du principe que tout code qui n'est pas utilisé est du code inutile. S'il a jugé utile d'écrire ce code, c'est qu'il en trouve ** peut-être ** une utilité "ailleurs". Ne crois tu pas?
Et c'est là que tu te diras (peut-être) que "oui, mais, au fait, nous parlons d'une fonction qui renvoie une valeur (une valeur clairement définie), pas d'une donnée qui permet de représenter cette valeur. Or la partie la plus importante dans le code d'une fonction c'est son nom, parce que, bien plus que de savoir comment la fonction obtient le résultat qu'elle fournit, ce qui intéresse l'utilisateur du code, c'est de savoir quel service la fonction en question est capable de lui rendre".
Et, du coup, tu vas peut-être t'intéresser à la fonction en elle même. Qui est -- sauf erreur de ma part -- la fonction (membre de la classe PieceVisitor ) visit(Piece) et ses différentes surcharges (pour ConcretePiece<unTagParticulier>).
En prenant un tout petit peu plus de recul, tu remarqueras que toutes ces surcharges (à l'exception de deux, en fait) sont déclarées virtuelles, ce qui "tout à fait logique" étant donné le nom de la classe (PieceVisitor), qui indique clairement que nous avons affaire à une classe de base destinée à intervenir dans un patron de conception bien connu: le patron visiteur.
Bien que n'ayant pas relu mon livre depuis longtemps, je suis presque sur que j'avais expliqué clairement les raisons pour lesquelles j'envisageais ce patron de conception particulier, en expliquant pourquoi ses "mauvais cotés" (comme la multiplication des surcharges qui est à craindre) ne posaient pas de problème particulier (parce que nous avons affaire à un nombre clairement défini de pièces différentes, et que ce nombre ne variera jamais, dans le cas présent).
En prenant encore un peu plus de recul (et en ayant lu le livre), tu te serais enfin rappelé que je ne voulais pas être absolument obligé de redéfinir le comportement de toutes les surcharges de cette fonction visit, à chaque fois que je créais une classe dérivée de PieceVisitor.
Comme je te l'ai dit, je suis au moins aussi fainéant que toi (et peut-être même encore plus, d'ailleurs ). Si bien que, si je peux mettre à un endroit donné du code qui m'évitera d'avoir à mettre le même code à des dizaines d'endroits différents, tu peux être sur que je vais choisir cette solution. Du moins pour autant que le code que je n'aurai mis qu'à un seul endroit puisse convenir comme "comportement de base" pour les endroits où j'aurais du le copier.
Hé bien, c'est exactement ce que j'ai fait. Simplement, pour pouvoir se rendre compte du "génie de l'idée" ( ) il faut avoir une vision globale de l'ensemble du problème, qui est:
j'ai les six pièces de base du jeu d'échec (pion, tour, cavalier, fou, dame et roi)
j'ai une pièce "qui n'en n'est pas une", et à laquelle toutes les questions que l'on pourrait vouloir lui poser n'auront jamais qu'une seule réponse: non
j'ai des dizaines de questions susceptibles d'être posées à chacune de ces pièces
Si, quelle que soit la pièce envisagée, quelle que soit la question qui lui est posée, je peux faire en sorte que la réponse que j'obtiendrai -- à défaut d'avoir redéfini le comportement permettant d'obtenir une réponse potentiellement différente -- fait que l'ordre que je m'apprête à donner à cette pièce sera refusé "d'office", je peux être sur de ne jamais donner une ordre à n'importe quelle pièce qui aille à l'encontre de ce qu'elle peut faire.
Et donc, ce comportement qui a l'air "inutile" pris hors de tout contexte prend finalement tout son sens au sens de l'image générale globale: je renvoie une valeur par défaut pour n'avoir pas à le faire lorsque j'en viens à me poser une question qui n'aurait simplement pas de sens au vu de la pièce à laquelle je m'adresse.
Par exemple, si je voulais savoir si la pièce P peut rocker et que P est en réalité un fou, ben, la question en elle même n'a pas de sens (car seul le roi et la tour peuvent rocker ensemble). Ce qui n'empêche que je veux avoir la réponse, vu que je n'ai pas envie de m'inquiéter du type réel de P. Et la seule réponse valable que je m'attend à recevoir dans ce cas, c'est : ben non P ne peut pas rocker (et pour cause, vu que c'est un fou)
Simplement, en donnant cette réponse comme "valeur par défaut", je sais que je n'aurais pas à m'inquiéter "plus tard" de définir le comportement adéquat pour les pion, les fous, les cavaliers et les dames, car j'aurai directement la bonne réponse en ce qui les concerne.
Tu me diras que je me suis peut être "un peu cassé la tête" pour trouver cette manière de faire. Mais qu'est ce que cela a pu faciliter mon travail par la suite
JadeSalina a écrit:
et la plupart des fichiers ne contiennent aucune logique, difficile donc de savoir ce qui se passe.
Tu as très mal regardé en fait... Car tous les fichiers ne contiennent en définitive que la logique qui les intéresse au premier plan, et parce que j'ai appliqué à la lettre le fameux conseil DRY (don't repeat yourself): si une logique quelconque peut être réutilisée "telle quelle", elle mérite d'être définie sous la forme d'une fonction particulière
JadeSalina a écrit:
Il y a une fonction `fillAllowedMoveList` qui renvoie une std::list (pas même un std::vector), mais surtout on n'a pas envie d'allouer de la mémoire à chaque fois qu'on veut récupérer les mouvements, il aurait été mieux de faire un truc du genre que la fonction prenne un itérateur begin/end et écrive dedans, comme ça si on a déjà de la mémoire on peut la réutiliser (et rien n'empêche d'avoir quand même une autre fonction par dessus qui alloue le vecteur ou autre si c'est vraiment ce qu'on veut).
Ce n'est qu'un détail d'implémentation, que j'aurais tout aussi bien pu cacher derrière un alias de type, et que rien ne t'empêche de modifier à ta guise pour déterminer à l'aide de benchmarks si l'un est au final mieux que l'autre.
J'ai utilisé std::list parce que c'était la collection dont la sémantique s'adaptait le mieux à l'usage que je prévoyais d'en faire: pouvoir rajouter des déplacement potentiels les un derrière les autres, savoir, pour une pièce particulières s'il y avait des déplacements possibles, et éventuellement les parcourir dans l'ordre dans lequel ils ont été "trouvés". Le tout en pouvant les supprimer une fois qu'ils sont devenus inutiles.
L'utilisation de la mémoire en elle même ne pose pas vraiment de problème, car, dans le pire des cas, tu as
2 * 8 pions, qui ont chacuns 1, voire 2 déplacement possibles (allez, très rarement trois :D) (48 déplacements)
2* 2 tours qui ont chacunes 14 déplacements possibles (56 déplacements)
2* 2 fous qui ont chacuns 14 déplacements possibles (56 déplacements)
2 dames qui ont chacunes 28 déplacements possibles (56 déplacements)
2 rois qui ont chacuns 8 déplacements possibles (16 déplacements)
Soit le total faramineux de ... 232 déplacements valides ou supposés l'être. Quand on sait qu'un déplacement est composé de 2 size_t (des unsigned long long int), et qu'il faut -- a priori -- deux pointeurs (l'équivalent de ... 2 unsigned long long int ) pour représenter les éléments d'une liste, mais que l'utilisation d'une liste permet de rajouter les éléments en temps constant, on se dit que "la perte" de deux pointeurs par éléments ne posera pas vraiment problème: on parle royalement de ... 7 ko de mémoire, là ... Quelle quantité pharaonique
JadeSalina a écrit:
Mais le plus gros problème c'est dans la structure générale. Par exemple, pour abstraire les entrées/sorties (ce qui est une chose absolument magnifique à faire bien entendu), et bien il y a une interface abstraite et le jeu appelle ces fonctions virtuelles par exemple pour dire "affiche à qui c'est le tour", "affiche le gagnant", etc. Je trouve purement et simplement que ce n'est pas seulement bof, c'est carrément le contraire de ce qu'on voudrait faire. Tout simplement car la structure de l'affichage est imposée par le jeu (qui est censé ne rien savoir et en avoir rien à fou*** de l'affichage, je le rappelle), alors pourquoi c'est lui qui fait des appels virtuels ?
Encore une fois, tu confonds le quoi, le pourquoi et le comment...
Le quoi, c'est: j'ai un échiquier (avec les différentes pièces correctement placées) et deux joueurs, et je veux:
récupérer la commande introduite par le joueur, mais pas n'importe lequel: le joueur dont c'est le tour à jouer
Les commandes introduites par le joueurs (et validées) devront être répercutées sur les données métiers, ce qui est exclusivement l'affaire de la partie
certaines de ces commandes peuvent mettre la partie dans des situations bien particulières (échec, pat, mat, abandon) que seule la partie est apte à définir (que seule la partie est en mesure de déterminer si elles surviennent ou non)
En plus de l'échiquier, le système s'occupant de l'affichage doit être en mesure de mettre ces situations en évidences. Mais ...
comme je l'ai dit, il n'y a que la partie qui soit apte à déterminer si ces situations surviennent. Ce n'est donc pas à l'affichage de déterminer si elles surviennent ou non.
Le comment représente la manière dont on va s'y prendre pour obtenir le quoi.
L'idée est simple: chaque joueur a son propre système d'entrées. Pour ce que l'on en sait, cela pourrait être un simple clavier avec les lettres de A à H inclus et les chiffres de 1 à 8 inclus (plus éventuellement une touche "help"), que cela devrait fonctionner.
Et les deux joueurs devraient pouvoir avoir des systèmes d'entrées potentiellement différent.
Par contre, l'affichage est forcément "commun" en cours de partie. Peut importe la manière dont l'affichage est effectivement effectué, ce qui importe c'est que les "situations particulières" que la partie est capable de repérer puissent, d'une manière ou d'une autre, être représentées -- peu importe comment -- par le système d'affichage qui sera utilisé.
Ou je vais même encore dire les choses de manière plus précise: ce qui importe, c'est que la partie (qui est la seule à pouvoir déterminer si certaines situations particulières surviennent ou non) puisse, quoi qu'il arrive, envoyer l'ordre au système d'affichage de faire apparaitre clairement la survenue de ces situations particulières.
Et ce, quelle que soit la manière dont le système d'affichage utilisé pourra s'y prendre pour mettre la survenue de ces situations en évidence (si tant est qu'il le fasse, d'ailleurs).
Il est donc "tout à fait logique" que le système d'affichage expose -- lorsqu'on ne sait pas encore quel type d'affichage sera utilisé -- des fonctions (virtuelles pures) permettant de lui transmettre les ordres adéquats.
Et il est également tout à fait logique que la partie utilise ces fonctions virtuelles pures pour transmettre les ordres lorsque le besoin s'en fait sentir. En cela, nous ne faisons que respecter le dernier principe SOLID : le DIP (Dépendancies Inversion Principles): ce sont les détails (AKA la logique intrinsèque de la partie) qui doit dépendre des abstractions: quand la logique estime qu'il est utile d'afficher un élément particulier, elle s'adresse à l'abstraction qui s'occupe de le faire.
JadeSalina a écrit:
Dans le code du livre, on dirait que le système d'output est certes personnalisable, mais très peu, comme si c'était destiné à être utilisé dans la console,
Dans quelle mesure cette impression n'est elle pas essentiellement due au fait que le seul système de sortie que j'ai présenté soit effectivement une sortie en mode console?
JadeSalina a écrit:
Mais ce qui est montré dans le livre n'est certainement pas une façon vraiment générique et "efficace" d'organiser le code.
Et pourtant...
As tu, par exemple, remarqué que le code responsable de l'affichage des différentes commandes utilise deux paramètres templates: le premier correspond à un tag représentant spécifiquement le système d'affichage, alors que le deuxième correspond à la commande qui est effectivement traitée.
Cela signifie que si je défini un autre système d'affichage (qui hérite de OutputSystem), par exemple un système d'affichage 3D utilisant OpenGl, et que je rajoute un tag pour ce nouvau système de sortie (par exemple le tag OpenGL3D), je peux fournir une spécialisation de la fonction printMe pour chacune des commandes susceptibles d'être appelées et dont le comportement serait adapté du fait de l'utilisation de ce tag OpenGL3D.
JadeSalina a écrit:
Ou alors allez-y, faites un Chess 3D avec animations en utilisant cette lib, et si possible en ayant un code clair et pas rempli de hacks dus au fait que le système impose une structure qui n'est pas forcément celle qu'on voudrait (par exemple un jeu graphique tourne à 60 fps, mais le "tick" du jeu ne se fait qu'en cas d'action du joueur, absolument pas 60 fois par seconde)
Il n'y aurait pas vraiment de problème
Car nous sommes d'accord qu'un affichage 3D sera sans doute effectué à 60FPS. Cependant, l'affichage pourrait même se faire de manière encore plus rapide, il n'y a qu'un nombre clairement limité de situations dans lesquelles les données d'affichage devront être mises à jour. Et, devine lesquelles?
Gagné:
lorsqu'une commande modifie la position d'une pièce
lorsque l'on alterne les joueurs "actifs"
lorsqu'un joueur est mis en situation d'échecs, de mat ou de pat
lorsqu'un joueur décide d'abandonner
Or, il se fait que ce sont, justement, les situations qui sont envisagées comme "point de variation" au niveau de la classe OutupSystem
- Edité par koala01 9 mai 2022 à 21:13:32
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
un simple inconnu qui passe incognito sur le forum
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
> "On s'en fout... La complexité vient [...] au niveau de la classe OutupSystem ;)"
Est-ce le record du message le plus long du forum (hors code )?
Oh là là... mon dieu... non
gbdivers a écrit:
Je pense pas. Koala a déjà fait des messages qui dépassent la limite maximale du forum et devaient être coupé en 2.
Et sur d'autres forums
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
Alors je crois que tu pourrais publier un autre livre : un best of de tes interventions sur les forum. Il y a matière !
Plus sérieusement, c'est toujours très intéressant en tout cas. Merci !
Après plus de vingt ans à écumer les forums, et -- sauf erreur de ma part -- plus de 30 000 interventions, le choix de celles qui mériteraient d'être éditées risque d'être ... pour le moins difficile
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
Alors je crois que tu pourrais publier un autre livre : un best of de tes interventions sur les forum. Il y a matière !
Plus sérieusement, c'est toujours très intéressant en tout cas. Merci !
Blague a part, je paierai pour un tel bouquin J'ai beaucoup apprécié (et j’espère autant appris de) la lecture du livre de notre Vombatiformes national, mais pour une raison que j'ignore, ses interventions sur le forum me semblent plus facile a retenir et plus didactiques. Ce n'est peut être qu'une impression, mais c'est une impression assez forte pour me retenir ici
ou encore des fonctions qui renvoient des pointeurs nus (ok ça peut passer), mais là ça renvoie le retour de new !!!!)
Oui, et alors? la fonction make_unique n'existait pas à l'époque, et cette fonction qui renvoiie un pointeur pour lequel la mémoire a été allouée avec new n'est utilisée que dans un contexte bien particulier: la mise en place des pièces sur l'échiquier.
Ce contexte est suffisamment précis et suffisamment "maitrisé" que pour que cela ne pose pas de problème particulier à le faire, d'autant plus que ce contexte va faire faire prendre nos pointeurs nus en charge par des unique_ptr.
Alors là merci beaucoup parce que j'ai dit ça car c'est ce qu'on lit partout mais je trouve que c'est une très très bonne idée de se permettre de faire ce genre de choses "en interne" dans un contexte maitrisé comme vous dites au lieu d'essayer à tout prix de suivre des conventions abstraites qui ne ferait que compliquer les choses. Effectivement on nous dit toujours qu'il faut utiliser le plus de trucs tous faits et le plus d'abstractions partout, alors que je trouve qu'il vaut mieux se permettre quelques "libertés" qui facilitent l'implémentation ou améliore les performances quand on est dans du code en interne de plus "bas niveau". Du moment que ces détails ne fuitent pas dans le reste du code c'est bon. Par exemple au lieu de faire un calcul "tordu" et "peu lisible" isolé dans une fonction, il y en a qui vont à tout prix chercher à utiliser des trucs existants pour que la moindre ligne de code soit "lisible", au détriment de la performance, par exemple dans le windows terminal, la fonction _SetGraphicsRenditionRGBColor (https://github.com/microsoft/terminal/blob/v1.8.1444.0/src/renderer/vt/VtSequences.cpp#L266) est écrite d'une manière "lisible" mais terriblement inefficace, on leur propose de la remplacer par ceci : https://github.com/microsoft/terminal/issues/10362#issuecomment-856625365
Ils répondent que c'est pas lisible mais est-ce qu'on s'en foutrait pas un peu ? Bah si exactement, on est là dans du code bas niveau, ce qu'on veut c'est qu'il soit performant. La personne qui va appeler cette fonction en a rien à cirer de comment elle est implémentée, du moment qu'elle fait ce qu'on veut et rapidement. Au pire on rajoute des commentaires pour expliquer le "trick" et ça roule, on se retrouve avec un code rapide. Ce n'est pas la peine que l'entièreté du code soit traité avec le même niveau d'abstraction, surtout si c'est pour un payer le prix en performance. Et de toute façon c'est pas non plus du code qui est destiné à changer souvent, donc raison de plus pour "l'optimiser" et on en parle plus, au lieu de vouloir absolument le rendre lisible au détriment du reste.
Je n'ai pas le temps de trouver tous les passages où Casey a parlé de ça, mais là il explique pourquoi il ne faut pas complexifier les choses :
Je n'arrive pas a comprendre comment on en arrive à un tel culte de la personne.
<long message que j'avais commencé à écrire...>
Je voulais expliquer en quoi, encore une fois, l'extrait sur Scott Meyers est du caca (parce que Casey critique un talk qu'il n'a manifestement pas vu... surtout que globalement, ce que Casey dit n'est pas faux, ce sont des choses assez basiques et bien connues) et surtout TA conclusion est aussi du caca (parce que Casey ne dit à aucun moment qu'il ne faut pas écouter les talks de Scott Meyers).
Ton fanboysime est juste une perte de temps. Si certains veulent regarder et discuter des extraits des vidéos de Casey, lancez votre propre discussion en expliquant ce que vous trouvez de bien et de mal dans ce qu'il dit et on pourra discuter. Mais sans Jade.
Sur deux jambes, comme depuis une petite cinquantaine d'années... pourvu que ca dure
Ah, au fait, il n'y a aucun besoin de me vouvoyer ou de me donner du monsieur, M. Dunski, c'est mon père, moi, je ne suis pas encore vieux assez que pour être vouvoyé
JadeSalina a écrit:
Oui mais c'est comme si je dit "il faut faire le meilleur truc possible", c'est une phrase dans le vent qui apporte rien d'intéressant
Oh, ce conseil est beaucoup plus profond que tu ne pourrait le croire, même s'il est très générique...
Car il faut garder en mémoire le fait que la moindre ligne de code que tu vas écrire n'a de sens que si elle est utilisée. Si ce n'est pas le cas, tu vas tout simplement perdre ton temps à l'écrire.
Et le problème, c'est que tu ne sais a priori absolument rien de la personne qui va utiliser le code que tu as écrit. Ce sera peut-être toi... ou pas. Et même si c'est toi, ce sera peut-être des mois ou des années après avoir écrit le code, ce sera peut être le jour où tu sera inquiète pour ton gamin qui s'est cassé une jambe et que ton mari a du conduire à l'hôpital.
Ce sera peut-être après t'être engueulée avec ton boss ou avec un membre de ton équipe.
Et ce sera surtout, alors que tu as écrit des milliers (voir, des dizaines de milliers) d'autres lignes de code.
Enfin, bref... Ce qu'il faut comprendre de tout cela, c'est que, même si c'est toi qui utilise le code que tu as toi même écrit, les raisons qui font que tu risque de ne pas utiliser ce code de manière correcte sont tellement nombreuses que la probabilité pour que ce soit le cas est, comme pour le point godwin, proche de 1.
Cela ne sert à rien de se poser la question "est ce qu'il y a le moindre risque pour que j'utilise cette ligne de code de manière incorrecte?" car tu peux être sure que cela arrivera ** forcément **.
Tu peux donc directement passer à la deuxième question qui est "quand vais-je utiliser cette ligne de code de manière incorrecte?". Et la réponse à cette question est toujours très désagréable, car elle est systématiquement "au pire moment qui soit".
L'idée est donc de mettre des "jalons" autour de ton code, qui permettent de dire "voilà: ceci est une utilisation correcte, et ceci est une utilisation incorrecte". L'avantage, c'est que tu vas pouvoir profiter du compilateur (ou de la période de tests) pour te dire "hé, ma belle, là, tu as fait une connerie, il faut la corriger".
Et tu peux me croire sur parole, le compilateur, il sera toujours plus buté que toi
Si bien que, plus tu met des jalons dans ton code pour dire "ceci est une utilisation incorrecte du code existant", plus tu pourras avoir un code "de qualité", qui fait non seulement ce qu'il est censé faire, mais qui le fait bien, qui fourni le résultat que l'on attend de sa part, et, avec un peu de chance, qui le fera "aussi vite que possible" et en requérant "un minimum de ressources".
Les règles pour jalonner son code sont relativement peu nombreuses:
Ce qui n'a pas à être modifié devrait être constant
ce qui n'a pas à être copié ne devrait pas pouvoir l'être
on ne fait jamais confiance au code appelant pour nous donner des informations cohérentes
ce qui n'est pas autorisé est interdit: on ne donne aucun moyen de faire ce qui n'est pas autorisé
Si déjà tu peux suivre ces quatre lignes de conduites dans ton code, tu peux considérer que tu t'évites 90% des problèmes qui pourraient survenir par la suite
Donc, si je comprends bien, il ne faudrait pas écouter Scott Meyers, par contre, ce serait un crime de ne pas écouter ce monsieur qui avoue n'avoir plus fait de C++ depuis des années, et qui ne se gène absolument pas pour dire que tous les développeurs C++ sont incompétents (plus incompétents que lui, qui ne l'est déjà pas vraiment)?
Hummm... A choisir, je préfère écouter Scott Meyers
JadeSalina a écrit:
Alors là merci beaucoup parce que j'ai dit ça car c'est ce qu'on lit partout mais je trouve que c'est une très très bonne idée de se permettre de faire ce genre de choses "en interne" dans un contexte maitrisé comme vous dites au lieu d'essayer à tout prix de suivre des conventions abstraites qui ne ferait que compliquer les choses. Effectivement on nous dit toujours qu'il faut utiliser le plus de trucs tous faits et le plus d'abstractions partout,
Et l'on a raison d'insister sur ce point en période d'apprentissage, car un débutant n'aura pas le recul nécessaire, pas forcément toutes les informations à prendre en compte, pour pouvoir faire "à sa main" les choses correctement.
Les techniques éprouvées que l'on met en avant sont garanties : tu es face à un besoin particulier, voici un moyen éprouvé pour le remplir et qui te permettra de te focaliser sur ce qui est vraiment important.
Ce n'est qu'après, lorsque le développeur aura pris un peu (beaucoup) de bouteille, qu'il pourra (éventuellement) se dire que cette "solution toute faite" présente "un certain nombre de défauts" qui l'embêtent très sérieusement et qu'il pourrait éviter en produisant sa solution "personnalisée".
JadeSalina a écrit:
Effectivement on nous dit toujours qu'il faut utiliser le plus de trucs tous faits et le plus d'abstractions partout, alors que je trouve qu'il vaut mieux se permettre quelques "libertés" qui facilitent l'implémentation ou améliore les performances quand on est dans du code en interne de plus "bas niveau". Du moment que ces détails ne fuitent pas dans le reste du code c'est bon.
Cela reste effectivement la prérogative du développeur.
Encore faut il qu'il sache exactement ce qu'il fait, qu'il maitrise l'ensemble des tenants et des aboutissants du problème, et qu'il soit effectivement capable de faire en sorte que cela ne fuira pas
Alors, excuses moi d'avance, vu que cela va ressembler à une attaque personnelle, mais, en ce qui te concerne toi précisément, tu n'a pas encore la "maturité" nécessaire pour prendre ce genre de décisions "toute seule".
Tu n'as pas encore assez d'expérience, pas assez de recul pour arriver à comprendre que tu vas prendre des risques, que tu vas certainement faire les choses "moins bien" que les solutions qui te sont proposées, et que, au final, tu auras au mieux perdu du temps à faire les choses toi-même avant de repasser à "la solution toute faite", et, au pire, que tu te retrouveras avec quelque chose de tout à fait bancal.
Un type (ou une bonne femme, ne soyons pas sexistes ) qui a cinq ou dix ans d'expérience (voire plus) et qui a "suffisamment fait joujou" avec les différents tenants et aboutissants que pour pouvoir "élargir sa vision du problème" sera beaucoup plus apte que toi lorsqu'il s'agira de décider de faire "à sa sauce".
Mais ne t'en fais pas: tu peux sans aucun problème y arriver toi aussi. Il faut juste que tu accepte l'idée que handmadehero n'est clairement pas la référence la plus stable sur laquelle tu puisse t'appuyer
JadeSalina a écrit:
Mais plutôt que d'envisager des points de variations, pourquoi ne pas faire en sorte que le jeu ne s'en occupe pas du tout,
Parce que tu n'as simplement pas le choix: Tu as trois "modules" séparés qui sont:
la partie métier / le modèle (l'échiquier, les pièces, les règles)
la partie "entrées utilisateur" (on pourrait dire: le contrôleur)
la partie "affichage" (on pourrait dire "la vue")
Ces trois éléments doivent être "aussi indépendants que possible" les uns que les autres, et pourtant il faut bien qu'ils puissent communiquer les uns avec les autres:
Si la vue n'a pas les données métier pour l'affichage, elle ne saura rien afficher
si la partie métier n'a pas le contrôleur pour lui dire quelle modification apporter, la partie ne se joue tout simplement pas
Si le contrôleur n'a pas la partie métier pour savoir si une action est "légale", il risque de permettre des actions que les règles du jeu n'acceptent pas (comme le fait de faire passer le roi de A1 en H8)
Il faut donc mettre "un protocole" en place pour que les informations "utiles et nécessaires" puissent être transmises "en temps voulu" entre tout ce beau monde! Et ce protocole, il est donné par ... je te le donne dans le mille, les fonctions virtuelles, par ces fonctions qui peuvent adapter leur comportement à la situation réellement subie.
Dis toi bien que je me fous pas mal de la manière dont le joueur introduit ses commandes. Je me fous pas mal de la manière dont le jeu d'échec est présenté au joueur. Je veux que les règles du jeu d'échecs soient respectées.
Et je veux que le joueur puisse introduire des commandes et avoir un aperçu de l'état de la partie à un instant T (ainsi que "quelques situations particulières dues aux règles du jeu).
Les "points de variation" sont, justement, là pour permettre "à celui qui voudrait" de mettre "n'importe quel système d'affichage ou de prise de commandes" en place tout en s'assurant que ce système sera en mesure de ... communiquer avec le reste de manière cohérente.
JadeSalina a écrit:
L'implémenteur de la lib ne pense pas forcément à tous les cas d'usage,
Voyons déjà de quel implémenteur de la lib on parle... Je présumes que tu parles de l'implémenteur de la lib OpenGL, SFML, Qt ou autre, bref de n'importe quelle bibliothèque permettant d'afficher des données ou d'introduire des actions?
Ces implémenteurs là, il font leur travail, et on peut partir du principe qu'ils le font bien . Moi, je fais le mien -- et je le fais bien -- en mettant en place un protocole qui permettra à mes données métiers ainsi qu'au controleur et à la vue qui seront mises en place de communiquer les informations utiles en temps et en heure.
JadeSalina a écrit:
donc autant laisser l'utilisateur libre plutôt que de lui imposer des contraintes arbitraires.
Ben non, ca, c'est ma prérogative en tant que développeur du projet: j'avais besoin d'un protocole particulier pour permettre la communication, il fallait que je le définisse. C'est ce que j'ai fait
Si quelqu'un veut utiliser ma base avec n'importe quelle bibliothèque existante, il devra accepter l'idée que la communication entre les différentes parties se fera selon le protocole imposé.
Si tu venais à développer un navigateur web, tu serais aussi soumise à différents protocoles (http, et autres), et tu devrais les respecter, nous sommes bien d'accord?
Pourquoi devrais-je, sous prétexte que mon code ne sera sans doute utilisé que par trois pelés et deux tondus, refuser d'imposer un protocole qui s'avère de toutes façons nécessaire juste pour "laisser l'utilisateur libre de faire comme il le sent"?
On en revient toujours au même point: il faut rendre les choses faciles à utiliser correctement et difficiles à utiliser de manière incorrecte. La vue, le contrôleur et la partie métier doivent régulièrement communiquer les uns avec les autres.
Le protocole mis en place permet de faciliter à "qui veut le faire" la mise en place d'un communication entre ces éléments (de la manière prévue) et rend difficle la mauvaise utilisation du protocole. Nous sommes donc exactement dans les clous de l'objectif à atteindre
Maintenant, il est tout à fait vrai que j'aurais pu faire les choses de manière totalement différente. Cependant, il faut aussi garder en tête que ce code était -- comme l'a si bien fait remarquer gbdivers -- essentiellement destiné à servir de support à ce que je dis dans le livre.
Et ce que je voulais surtout, c'est avoir un code:
qui puisse compiler et fonctionner "tel quel"
qui puisse -- si vraiment ca faisait plaisir aux gens -- évoluer pour utiliser d'autres systèmes spécifiques
Ce code ne ferme absolument aucune porte qui présenterait un intérêt quelconque à rester déverrouillée. Si des jalons sont placés quelque part pour dire que "c'est par là qu'il faut aller" (sous entendu: "et vous ne pourrez pas aller dans une autre direction), c'est parce que la direction indiquée n'offre -- du point de vue du projet -- aucune alternative censée
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
Moi je trouve dommage que des gens doués disent que d'autres gens doués font de la merde.
Je pense qu'ici nous avons tous un certain niveau en programmation. Alors bien sur on peut toujours améliorer des choses, on peut toujours corriger quelques défauts objectifs. On peut aussi débattre. Mais on peut aussi garder différents styles, et ne pas forcément vouloir être "le meilleur".
Je pense qu'ici, on se lit régulièrement, personne n'a plus à faire ses preuves : on sait qu'on a affaire à des gens passionnés qui touchent bien.
Et ce monsieur Casey qui - parait il - conchie les commités de C++, franchement quel est son problème personnel ? A quel moment on a besoin d'écraser les autres comme ça ? Ben moi je pense qu'on écrase les autres quand on a de gros doutes sur sa propre vie.
Et il faut arrêter avec les arguments d'autorité "Casey a dit que...". Moi ce mec manifestement complexé ne m'attire pas du tout. C'est pas comme ça que je vois l'entraide informatique, en disant que ce que font les autres c'est de la merde.
EDIT :
Je vais ajouter un peu de ma vie perso. Je suis développeur dans une boite, avec plein d'autres développeurs.
Plein de mes collègues ont des façons de programmer qui ne sont pas les miennes. Parfois on argumente, parfois on évolue, mais parfois on aime notre façon de faire. Pareil certains de mes collègues n'adopteraient pas mon style.
Donc on a deux solutions :
- Soit on se tolère et on accepte les façons de faire, tant que le boulot fonctionne, tout en pouvant discuter sur des méthodes qui pourraient être plus efficaces. Mieux, on se complimente mutuellement quand on arrive à des résultats, comme une équipe soudée, et la boîte marche super bien.
- Soit on dit aux autres que leur façon de programmer est merdique, on se la joue solo et on emmerde ses collègues, l'ambiance pourrit rapidement, et la boîte finit par se disloquer.
Moi je trouve dommage que des gens doués disent que d'autres gens doués font de la merde.
Je suis pas d'accord sur ce point. Je pense que Casey est très loin d'être doué. (Ou tout au moins, s'il l'est, ça ne se voit pas dans ses vidéos)
- son code est du vieux C, sans rien d'extraordinaire (pour ce que j'ai vu) en termes techniques. (Clique sur le lien dans le message de koala01 et balade toi dans la vidéo pour voir des exemples de code)
- handmadehero a été commencé en 2014 et pour le moment, on a juste un visuel assez simple (digne d'un RPG Maker), même pas un début de game play
- 1935 a été commencé en 2016 et rien du tout pour le moment
- meowtheinfinite est sorti, mais c'est juste une BD, pas un software
En termes d'accomplissement, j'ai du mal à le classer dans "gens doués".
En termes techniques, par rapport aux différents extraits vidéos donné par Jade que j'ai regardé (cf les précédentes critiques que j'ai fait), il a une position extrêmement arrogante, ce qui l'empêche (a mon avis) d'apprendre correctement. Cf le premier message de Jade dans cette discussion : l'idée est "si ca vient pas de moi, si je n'ai pas testé moi même, alors je rejette".
Regarde aussi l'extrait vidéo donné par Jade a propos de Scott Meyers et donne moi ton avis : est-ce que tu penses que Casey a vu le talk de Scott Meyers avant de le critiquer ? (Mon avis est que non).
Bref, pour moi, il est plus doué comme gourou pour obtenir des dons sur du vent que doué pour la programmation. On n'est pas juste sur un problème de style, mais bien un problème d'attitude (vieux con qui est trop arrogant pour apprendre).
Ok Casey critique parce qu'il aime pas les gens (c'est marqué dans sa bio twitter) mais de là à dire qu'il n'est pas doué là c'est pas possible. Dans Handmade Hero il montre comment tout faire de A à Z, le but n'est pas de faire un gros jeu 3D, d'ailleurs à la base le jeu était prévu pour être 2D mais il est parti en 3D vers l'épisode 300. D'ailleurs critiquer le résultat final en disant que c'est simpliste c'est ce que font les débutants quand on leur montre des petits jeux 2D et qu'ils trouvent que c'est pourri car ils ne voient pas ce qu'il y a derrière et eux veulent juste faire des MMORPG 3D. Il arrête pas de dire qu'il déteste coder le gameplay du jeu en lui même parce que lui ce qui l'intéresse c'est la partie moteur, par exemple ici :
Donc c'est normal que ça "n'avance pas" sur la partie visible. Il a fait un nombre incalculable de gros trucs dans Handmade Hero, le genre de truc que vous seriez du genre à planifier des réunions pendant que lui le fait dans l'heure. D'ailleurs j'avais parlé de l'histoire du windows Terminal, il a proposé un truc pour améliorer les performances et il s'est fait détruire parce que son truc était considéré comme un projet de recherche doctoral et absolument pas simpliste. Et un an plus tard ils ont implémenté un truc similaire et ils se gênent pas de dire que c'est "trivial" alors que c'est les même personnes qui disaient que c'était super dur (https://twitter.com/cmuratori/status/1522468481135902725).
En fait il a pratiquement tout fait dans Handmade Hero et sans la moindre librairie : interactions avec l'OS, lecture de musiques, chargement de PNG, chargement asynchrones d'assets, un renderer logiciel SIMD multithreadé, un système complet de debug pour avoir plein de stats, un système d'interface, son propre printf, et jusqu'à même des choses avancées (depth peeling, illumination globale temps réel, ...) et LE TOUT en parlant en même temps car il le fait le soir en live après son "day job".
Encore une fois je peux pas résumer mais par exemple dans cet épisode vous voyez un peu ce qu'il fait, c'est des choses quand même complexes (une traversée de kdtree en SIMD) : https://guide.handmadehero.org/code/day598/
Et une fois je suis tombée sur un live de Lynix où il disait qu'on ne regarder l'assembleur qu'en dernier recours voire même jamais, alors que Casey il manipule ça au quotidien, par exemple ici il essaie de faire dire au compilateur de mettre un CMOV : https://guide.handmadehero.org/code/day593/#6423
Et si vous trouvez que son code est "simple" bah tant mieux c'est l'objectif !! C'est normal vu qu'il n'utilise pas des templates et autres à tire larigot. Lui il se concentre plutôt sur le concret et les vrais objectifs à atteindre plutôt que suivre des conventions ou essayer de mettre de la sécurité partout, c'est pour ça qu'il code à la C, il n'a pas besoin du reste. D'ailleurs ce qu'il attend d'un langage c'est lui "permettre de l'aider à résoudre les problèmes complexes qui rencontre au quotidien alors que les autres essayent plutôt d'empêcher quelqu'un d'écrire après la fin d'un buffer" (https://guide.handmadehero.org/code/day586/#7865)
× 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.
git is great because Linus did it, mercurial is better because he didn't.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Le Tout est souvent plus grand que la somme de ses parties.
git is great because Linus did it, mercurial is better because he didn't.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Discord NaN. Mon site.
Discord NaN. Mon site.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Discord NaN. Mon site.