Haha, sur ce point je suis plutôt d'accord, il y a un mal français bien connu appelé "réunionite" : les gens enchaînent les réunions, toute la journée, et tout traîne puisqu'ils n'ont pas le temps de faire autre chose
Sinon, je n'ai pas trop le temps de le regarder ce Casey. Vous dites tous les deux qu'il n'aime pas les gens. Donc au moins il y a consensus la dessus.
Rien que pour ça, ce mec est un fruit pourri à ne surtout pas mettre dans une équipe en entreprise. Qu'il soit fort ou non.
Ce genre de gars, on fait super attention au niveau des recrutements pour les éviter.
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".
Soit, il a fait des trucs qui, quand tu les explique comme cela, ont l'air "pas mal"...
Mais dis moi, où est l'intérêt? Quand vais je pouvoir utiliser son code pour m'éviter d'avoir à refaire la même chose? Pourquoi devrais-je recoder ma fonction printf, alors que le langage que j'utilise m'en fournit une qui répond à mes besoins?
JadeSalina a écrit:
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,
Et il a bien raison... Faut juste en savoir assez sur l'histoire de l'informatique pour s'en rendre compte
Car, à la base, un ordinateur n'est qu'un ensemble de contacts par lesquels on peut faire ou non passer du courent, et que l'on peut observer pour savoir si le courent passe ou non.
L'assembleur a été développé pour permettre d'introduire une instruction sous la forme de ADD ebx 450 au lieu de devoir écrire la même chose en binaire (compréhensible par l'ordinateur) sous une forme proche de
01010001 111111001111 000111000010
| | |-> 450
| |-> adresse de l'acu EBX
|-> instruction : faire l'addition
C'était plus facile, et donc plus rapide.
Par la suite, on s'est dit qu'il était quand même "pas si facile" de garder en tête en permanence l'état de tous ces contacts, avec tout ce que cela pouvait impliquer. On a donc décidé de créer des langages dits de "troisième génération", que l'on peut qualifier de "proches du langage humain". C'est le genre de langage comme Ada, C, C++, java, python, Ocaml, et tous les autres.
Ces langages présentent l'avantage d'être "faciles à lire" pour ... l'humain qui doit l'écrire (à condition de connaitre les conventions, nous sommes bien d'accords ), et toute la conversion en langage machine se fait "automatiquement" grace au compilateur / à l'interpréteur.
L'énorme avantage de travailler de la sorte, c'est que l'on peut en profiter pour mettre en place des euristiques, des logiques qui permettent de choisir le meilleur moyen d'indiquer à l'ordinateur ce que l'on veut effectivement qu'il fasse; que les optimisations ne vont plus dépendre d'un humain -- qui n'aura jamais une vision globale de l'ensemble aussi précise que le programme qui fait la traduction -- pour que la meilleure manière de faire soit systématiquement choisie.
JadeSalina a écrit:
alors que Casey il manipule ça au quotidien,
Encore une fois, quel intérêt? En dehors du fait de pouvoir "se la pêter" en disant "oui, moi je manipule l'assembleur au quotidien et ceux qui n'en sont pas capables sont des cons", qu'est ce que cela lui apporte de le faire?
Attention, je ne prétend absolument pas qu'il est inutile de connaitre (ne serait-ce qu'un tout petit peu) l'assembleur. Je dis juste que le compilateur fera surement du bien meilleur boulot que toi pour le générer et que, si tu dois passer par l'assembleur pour corriger une de tes erreurs, c'est que ton code n'est clairement pas prêt à entrer en production
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
Ouais bon l'assembleur , j'en pratique depuis fort longtemps ,et ce qui est sur , c'est que ça ne sert à rien de le faire sois même , le compilo est bien meilleur. Pour déjà un tas de raison que les gens ne save pas (et je doute que Casey le sache aussi ) , qui est l'optimisation du cache , la connaissance des zero idiom , des macro-op , et de privilégier le parallélisme des instructions , et c'est tout sauf trivial sur du x86. En général on laisse le compilo gérer tout ça (fort heureusement , parce que c'est pas ultra pratique de coder de l'asm avec la doc d'intel sous les yeux ).
Mais je vais prendre un exemple plus concret J'ai écrit un code asm pour la multiplication de matrice un pote à écrit en asm la multiplication de matrice J'ai écrit un code C avec la multiplication de matrice Quel est le code qui a était le plus rapide ? (spoil la réponse 3 ) Et le pire c'est que le 3 étant écrit en C , on pouvait avoir un code encore plus rapide en mettant l'option avx x)
Je sais que l'assembleur , c'est vraiment parfait pour impressionner les débutants en prog (ouais je prog en assembleur en SIMD , je suis un ouf ) , enfaîte l'assembleur , c'est pas compliqué , la complexité et surtout de faire des choses complexe avec. Et surtout que l'optimisation (qui est le but quand on écrit en asm) est très pénible ,parce que tu dois le faire constamment. Surtout sur du x86 où quelque fois , il est difficile de savoir quel est le code le plus rapide (a part le test ) ou alors de se taper les 6000 pages d'Intel pour avoir une idée plus précise , ou alors laisser le compilo le faire et l'aider à bien optimiser C'est ce que fait d'ailleurs la plupart des personnes , y'a bien sur des optimisations qu'on peut faire en full asm , mais je pense aussi que ceux qui font ça connaissent assez mal les options du compilo et ce qu'on peut faire avec , et en jouant sur la façon d'écrire du code C (ou C++ ).
D'ailleurs programmer avec les SIMD (qui est appelé SSE ) , je trouve ça assez naturel , je n'ai jamais compris le bon fonctionnement du FPU du x86 , et donc j'ai toujours utilisé les instructions SSE qui sont bien plus facile et pratique (d'ailleurs ils ont un coté RISC comme approche ).
mais de là à dire qu'il n'est pas doué là c'est pas possible
Je maintiens et confirme. Tu es juste impressionné parce que tu débutes (manifestement) et que tu es impressionable, mais cela reste globalement du code et des techniques de base dans les JV et la 3D.
Et franchement, des arguments comme "ça n'a rien à voir ("it's night and day") avec son jeu professionnel 1935" ou "car ils ne voient pas ce qu'il y a derrière", ca ne convainc que des gens comme toi. Il faut être assez naïf pour accepter de genre d'argument, alors que c'est que du vent.
koala01 a écrit:
je manipule l'assembleur au quotidien et ceux qui n'en sont pas capables sont des cons"
HelbaSama a écrit:
je doute que Casey le sache aussi
Regardez les vidéos et ne croyez pas Jade sur parole. Casey ne fait pas de l'assembleur au quotidien a priori (dans tous les extraits que Jade a donné, c'est la première fois qu'on voit de l'assembleur) et il n'écrit pas d'assembleur du tout dans l'extrait. Il réécrit juste son code pour être branchless et regarde l'assembleur généré dans la call stack.
Et au final, la différence de perfs est dans l'erreur de mesure (entre 8.15ms et 6,93ms initialement, 6,87ms après "optimisation"), je ne suis même pas sur qu'il a optimisé quoi que ce soit.
On est d'accord que faire cela n'est plus du code débutant. Pour autant, c'est pas non plus du code que seuls les devs doués peuvent faire. Il faut juste avoir un peu d'expérience.
Casey, c'est globalement du vent et Jade ne fait qu'en rajouter une couche avec son fanboysime. Regardez les vidéos, c'est... "instructif" sur sa façon de travailler et penser.
Ecoutez je pense que vous êtes trop endoctrinés à vouloir à tout prix suivre des bonnes pratiques au lieu de vraiment réfléchir par vous même et faire des choses qui marchent concrètement. Il faut alléger le code source et pas rajouter des trucs inutiles de type "const noexcept nodiscard" qui n'apportent rien. Je pense que le monde du software va revenir aux bases avec un langage comme C et délaisser toute cette sémantique qui est un boulet qu'on se traine. Il y a des projets en ce sens comme https://handmade.network
Et d'ailleurs comment vous faites pour mettre toute cette sémantique en C ? Bah on s'en passe tout simplement, et oui c'est possible puisqu'il existe bien de gros projets faits en C et ce ne sont pas des nids à bugs. Et là vous vous dite que je dit n'importe quoi depuis le début mais imaginez 2 sec, vous faites une bibliothèque ou autre et tout d'un coup vous voulez pouvoir l'utiliser avec un autre langage, et bien ça va être une galère à porter si c'est écrit en C++ moderne, alors qu'avec un projet en C ça sera très simple. Donc oui on se met des sécurités à droite à gauche pour éviter de faire des erreurs (qu'on ne ferait même pas forcément) pour que au final on soit limité donc c'est dommage.
Et oui vous dites qu'on va certainement faire des erreurs qu'il faut prévenir, mais imaginez que ce ne soit pas le cas, bah du coup c'est comme si on prenait un parapluie alors qu'au final il ne pleut pas donc on s'est encombré pour rien.
Dans un autre sujet j'ai fait un truc très rigolo tout à l'heure c'est aller voir une rediff de Lynix et on a parlé de moi !!! C'était trop drole ! Du coup si Lynix passe par là je voulais vous dire que je ne veux absolument pas vous énerver ou quoi que ce soit, je veux juste propager la puissance de Casey qui permet en quelques heures de faire des choses qui prendrait des mois quand on se complique la vie inutilement , je ne voulais pas garder cette découverte magique pour moi. Peut être que je devrais passer sur le stream un de ces 4. Après vous faites comme vous voulez, vous n'êtes pas obligé de suivre ses précieux conseils qui permettent d'aller plus loin et plus vite, chacun fait comme il veut et c'est très bien, l'important c'est de faire ce qu'on aime dans la vie. D'ailleurs vous le dites vous même que vous êtes pas toujours d'accord entre vous donc voilà c'est normal chacun a ses petites préférences etc.
Il faut peut être attendre qu'un nouveau langage sorte et soit mieux pensé pour justement résoudre plus de problème parce que comme dit Casey, "The C++ standard commitee is too busy going on vacation to TheoryLand without actually ever making the language work" https://guide.handmadehero.org/code/day599/#314
je ne voulais pas garder cette découverte magique pour moi
Tu est tellement ridicule dans tes propos
JadeSalina a écrit:
Je pense que le monde du software va revenir aux bases avec un langage comme C et délaisser toute cette sémantique qui est un boulet qu'on se traine
Tu es tellement à côté de la plaque, c'est incroyable. Tu crois vraiment que Casey va convaincre les devs sérieux, avec ses jeux qui ne sont pas encore fini au bout de 10 ans ?
Tu es très drôle et naïf. Et trés chiant avec ton fanboysime.
"je veux juste propager la puissance de Casey qui permet en quelques heures de faire des choses qui prendrait des mois quand on se complique la vie inutilement ,je ne voulais pas garder cette découverte magique pour moi"
Voilà je pense que tu as bien résumé , enfaite tu ne te rend pas compte que le rapport que t'as avec Casey est le même que ceux qui sont avec une secte Idolâtrie du gourou ici Casey , et qu'il résoudra tout vos soucis , et ensuite la révélation. Étonnamment on pourrait penser que ce genre de dérive sectaire ne peut pas arriver en info , mais tu es la preuve que non.
on va certainement faire des erreurs qu'il faut prévenir, mais imaginez que ce ne soit pas le cas
Je n'avais pas fait attention à cette pépite. La gestion des erreurs n'est pas nécessaire, il suffit juste de ne pas faire d'erreur. Facile. Pourquoi on n'y avait pas pensé avant ??? Là, je reconnais qu'on est nul, la solution était toute simple !!!
Franchement, JadeSalina, tu fais exactement l'inverse du titre de ton post, le pire c'est que tu n'écoutes pas à plusieurs portes, mais à une seule...
Il serait vraiment temps que tu enlèves tes oeillères ou que tu commences à dév au niveau professionnel (là tu n'auras plus le choix de les enlever, tu te les feras arracher) pour comprendre à quel point tu es fermée, et à quel point tu dis n'importe quoi.
- Edité par dragonjoker 10 mai 2022 à 23:41:29
Si vous ne trouvez plus rien, cherchez autre chose.
Ouais bon l'assembleur , j'en pratique depuis fort longtemps ,et ce qui est sur , c'est que ça ne sert à rien de le faire sois même , le compilo est bien meilleur. Pour déjà un tas de raison que les gens ne save pas (et je doute que Casey le sache aussi ) , qui est l'optimisation du cache , la connaissance des zero idiom , des macro-op , et de privilégier le parallélisme des instructions , et c'est tout sauf trivial sur du x86. En général on laisse le compilo gérer tout ça (fort heureusement , parce que c'est pas ultra pratique de coder de l'asm avec la doc d'intel sous les yeux ).
Mais je vais prendre un exemple plus concret J'ai écrit un code asm pour la multiplication de matrice un pote à écrit en asm la multiplication de matrice J'ai écrit un code C avec la multiplication de matrice Quel est le code qui a était le plus rapide ? (spoil la réponse 3 ) Et le pire c'est que le 3 étant écrit en C , on pouvait avoir un code encore plus rapide en mettant l'option avx x)
Je sais que l'assembleur , c'est vraiment parfait pour impressionner les débutants en prog (ouais je prog en assembleur en SIMD , je suis un ouf ) , enfaîte l'assembleur , c'est pas compliqué , la complexité et surtout de faire des choses complexe avec. Et surtout que l'optimisation (qui est le but quand on écrit en asm) est très pénible ,parce que tu dois le faire constamment. Surtout sur du x86 où quelque fois , il est difficile de savoir quel est le code le plus rapide (a part le test ) ou alors de se taper les 6000 pages d'Intel pour avoir une idée plus précise , ou alors laisser le compilo le faire et l'aider à bien optimiser C'est ce que fait d'ailleurs la plupart des personnes , y'a bien sur des optimisations qu'on peut faire en full asm , mais je pense aussi que ceux qui font ça connaissent assez mal les options du compilo et ce qu'on peut faire avec , et en jouant sur la façon d'écrire du code C (ou C++ ).
D'ailleurs programmer avec les SIMD (qui est appelé SSE ) , je trouve ça assez naturel , je n'ai jamais compris le bon fonctionnement du FPU du x86 , et donc j'ai toujours utilisé les instructions SSE qui sont bien plus facile et pratique (d'ailleurs ils ont un coté RISC comme approche ).
- Edité par HelbaSama il y a 23 minutes
Ça dépend, dans mon domaine (traitement d'images/video) il peut arriver d’écrire certaines fonctions critiques avec des intrinsics voir de l'assembleur, on peut obtenir parfois un facteur de performances de 20 (rare mais ça arrive) comparé au code généré par le compilo (avec les options -O3, march=native et tout ce que tu veux), d'ailleurs tous les codecs vidéos existant ont leurs fonction critiques ultra optimisées.
Pour exemple tu peux aller voir, entre autre, le décodeur dAV1d qui contient 77% d'assembleur (après ça monte vite...) écrits par des psychopathes du domaine. Par exemple la transformée ADST (asymmetric discrete sine transform) inverse d'un bloc 16x16 pixels d'une profondeur de 12 bits (fonction judicieusement nommée inv_txfm_add_16x16_adst_adst_0_12bpc) prend 8990 cycles CPU dans sa version C et 646 cycles dans sa version ASM/AVX2, soit un facteur de 14.
Évidemment ces optimisations n'ont de sens que sur les fonctions critiques, qui seront appelées de millions/milliards de fois, tout le reste du code est en C classique.
Le propos de HelbaSama n'est pas vraiment de dire qu'on n'utilise pas directement l'assembleur, mais qu'on le fait en connaissance de cause, en ciblant avec du profiling ce qui a un intérêt d'être optimisé. Et que le reste du temps, il est préférable de faire confiance au compilateur.
Parce que tu donnes la raison toi même :
Orochi a écrit:
écrits par des psychopathes du domaine
Faire de l'optimisation bas niveau aussi poussé nécessite des compétences assez poussées, qui prennent des années à acquérir. (Et avant que Jade s'excite sur mes compétences, j'ai commencé l'assembleur au lycée, j'ai fait du calcul numérique intensif -- assembleur, SIMD, GPU computing, etc -- quand je bossais dans la recherche et je n'ai aucun problème à aller lire de l'ASM pour optimiser. Mais je connais aussi mes limites).
Penser qu'on fera mieux en termes d'optimisation que ceux qui font les compilateurs ou les libs spécialisées, il faut être très très bon et consacré beaucoup de temps. Ou être très arrogant.
J'ai bossé dans une entreprise de vidéosurveillance, sur la partie logicielle qui gère les flux vidéos. Et je n'ai aucun problème à le dire : je n'ai jamais eu les compétences pour prétendre écrire du code ASM qui serait plus performant que les libs que l'on utilisait. Le boulot d'optimisation consistait surtout à gérer correctement les allocations mémoires, étudier à fond les libs pour savoir comment les utiliser au mieux, tester de nouvelles libs (par exemple NVDEC pour le décodage vidéo sur GPU NVIDIA), etc. La quantité de boulot que cela aurait nécessité pour monter en compétence pour faire de l'ASM moi même n'était pas acceptable dans les temps de production habituels d'un logiciel industriel.
D'ailleurs je pense que Jade est juste impressionné par des trucs futile , en relisant son post : " 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
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". "
Donc Jade si tu rencontre quelqu'un qui code en full asm , sans lib et sans OS ,c'est Dieu ? Parce que j'en connais un ! x)
Plus sérieusement si tu considère Casey bon pour ça, alors je suis bien meilleur que lui , vu que je code bien sans OS , sans aucun lib externe sur des console retro , et en asm. Et quand je dis sans lib extern , c'est quelque fois sans la lib C , donc réinventer le printf ha ha, c'est une broutille pour moi
Est ce que ça fait de moi quelqu'un de bon ? Non Parce que réduire la programmation à cela est idiot , j'ai connu des mecs ultra calé en hardware/bas niveau ,mais qui était bien incapable de pondre un algo correct... Tu comprendra avec le temps que ce qui fait un bon programmeur (à mon sens ) et celui qui sait utilisé , les bons outils , les bons algo et la bonne architecture. Que tu sais taper sur le hardware en asm , ça fait pas de toi quelqu'un de "bon" , c'est une compétence utile dans certain domaine , mais ça te rend pas forcément bon à écrire du code. (de même que réinventer la roue carré )
Du coup si Lynix passe par là je voulais vous dire que je ne veux absolument pas vous énerver ou quoi que ce soit
Alors calme ta dissonance cognitive vis-à-vis de Casey, si quelqu'un est endoctriné ici c'est pas nous, sérieusement tu lis ce que tu écris ? ("je veux juste propager la puissance de Casey", si tu lisais ça à propos de quelqu'un d'autre tu te dirais probablement que la personne est aveuglée par son fanboyisme ...)
"J'ai été élevé par le grande Dalaï Lama et après quoi je me suis dit putain faut que j'aille dispenser la pensée Richnou à travers le monde !"
"Tout bien que tu détiens est un soucis qui te retient. Et Skyppy est la pour nos ôter tous nos soucis !"
Par contre, jadeSalina, quand tu dis que "const" ne sert à rien, je ne suis pas d'accord. ça garantit que la fonction que tu appelles ne modifie pas la donnée const. Bien sur au niveau code compilé ça ne change rien, puisque c'est un mécanisme pour le compilateur.
Grâce à const, tu demandes au compilateur de vérifier que t'as pas fait de conneries. C'est quand même rassurant !
Il faut alléger le code source et pas rajouter des trucs inutiles de type "const noexcept nodiscard" qui n'apportent rien.
Non, la première caractéristique d'un code, c'est d'être facile à lire par l'humain.
Parce que c'est l'humain qui va passer le plus de temps à le lire et à le modifier, c'est donc l'humain qui doit avoir le plus facile à le comprendre et que le compilateur ne "verra" le code qu'une fois que l'humain a fini de le modifier (ou du moins, qu'il croit avoir fini de le modifier).
La deuxième caractéristique d'un code, c'est de correspondre à un besoin. Et le meilleur moyen d'y arriver est encore de faire en sorte que chaque nom et chaque verbe utilisé dans l'expression des besoins apparaisse dans le code:
lorsque tu utilise un nom (par exemple : "il faut que les couleurs ... ) ce nom doit correspondre soit à une donnée soit à un type de donnée (en fonction du mot utilisé et du contexte dans lequel il est utilisé)
Lorsque tu utilise un verbe (par exemple "il faut trier ...") ce verbe doit correspondre à une fonction, parce que ce verbe désigne une action, un comportement et que ce sont les fonctions qui apportent les comportements
La troisième caractéristique d'un code est de faire en sorte de t'éviter de faire des erreurs. Parce que l'erreur est humaine et qu'en tant qu'humain, des erreurs, tu en fera forcément et pour de multiples raisons.
Si tu peux dire au compilateur que "ca, c'est une donnée qui n'est pas destinée à être modifiée (const)", "ca, c'est un retour de fonction qui doit impérativement être récupéré (nodiscard)" ou "ca, c'est un code qui n'est pas censé lancer une exception", ton compilateur devient ton meilleur allié, car, lui, il ne sera pas distrait par "le fil du temps", et que lui, si tu lui a dit que "ca ne peut pas" ou que "ca doit impérativement", il pourra vraiment s'assurer que c'est bel et bien le cas.
En ajoutant un const, un nodiscard ou un noexcept, on s'assure simplement qu'il y a au moins "une information" qui n'aura pas d'autre choix que de suivre des consignes simples et qui, sauf erreur de logique, ne pourra donc servir qu'à ce à quoi elle est destinée.
La quatrième caractéristique d'un code est de répondre à mon besoin, de faire exactement et en permanence ce que je vais attendre de lui. Si le code m'indique (par le nom d'une fonction) que "là, je vais trier <quelque chose>", je m'attend à ce que ce quelque chose soit effectivement trié en sortie de la fonction.
Les "jalons" que j'aurai posé (const, nodiscard et autres) seront là pour m'aider à ce que ce soit effectivement le cas, pour aider le compilateur à me dire que "oui mais eh, oh, stop, la tu fais une connerie, car tu m'a dit que <telle truc> ne pouvait pas être modifié"
Je m'en fous pas mal de savoir comment le tri sera effectué. Ce que je veux, c'est que ce soit fait.
Et une fois que ces quatre caractéristiques sont atteintes (dans cet ordre bien particulier), s'il me reste encore "un peu de temps" à consacrer au besoin en question et qu'il s'avère que j'ai effectivement un problème de performances, alors je peux ** éventuellement ** rajouter une cinquième caractéristique: que le code soit rapide.
Car cela ne m'intéresse absolument pas d'avoir un code rapide qu'il finisse avec une erreur une fois sur deux.
Parce que si mon algorithme est déjà "suffisamment efficace", j'obtiendrai le plus souvent une vitesse "raisonnable" par rapport au taf qui est effectué.
Parce que cela ne m'intéresse pas de gagner 0.0003 secondes sur un calcul qui prend 3 minutes et que si je dois modifier mon code pour qu'il aille plus vite (parce que je ne peux décemment pas attendre ces trois minutes de calcul), il faut que les modifications apportées me permettent de gagner au moins trente secondes (voire, même, idéalement 90 ou plus).
Parce que de tels gains en vitesse, ce n'est pas en faisant en sorte d'avoir un CMOV au lieu d'une quelconque autre instruction asm que je pourrai les obtenir, mais bien en repensant à l'algorithme, en évitant éventuellement des copies superflues, voire, en organisant effectivement différemment mes données en mémoire afin de profiter au mieux du cache du processeur.
JadeSalina a écrit:
délaisser toute cette sémantique qui est un boulet qu'on se traine.
Tu n'as simplement pas encore compris que cette sémantique, ce "boulet que tu te traine" est ton meilleur allié. Que c'est cette sémantique qui te permettra, demain, dans trois mois ou dans un an, de te rappeler exactement ce que tu voulais faire et comment tu l'as fait?
Mets toi bien en tête qu'un code est plus souvent lu et modifié qu'il n'est converti en code exécutable par le compilateur. Et pour que le code soit pérenne, il faut que la personne qui le lit puisse le comprendre, puisse savoir exactement pourquoi ce code se trouve précisément à cet endroit bien particulier et non dix lignes plus tôt ou dix lignes plus tard.
JadeSalina a écrit:
Donc oui on se met des sécurités à droite à gauche pour éviter de faire des erreurs (qu'on ne ferait même pas forcément) pour que au final on soit limité donc c'est dommage.
Et oui vous dites qu'on va certainement faire des erreurs qu'il faut prévenir, mais imaginez que ce ne soit pas le cas,
Au lieu d'espérer que tu ne feras pas d'erreur, tu dois te convaincre que tu en feras systématiquement...
Car nous ne sommes pas dans un monde de bisounours où tout le monde il est beau, tout le monde il est gentil.
Nous sommes dans resident evil ou dans walking dead, avec un tas de méchants qui n'attendent que l'occasion de t'agresser au moindre croisement. Et si tu n'es pas prête à te faire agresser, hé bien tu meurs.
L'erreur est humaine. Un gars qui prétend n'avoir jamais fait la moindre erreur est un menteur ou quelqu'un qui a un problème de mémoire.
Et des raisons de faire des erreurs, il y en a des tas. Que ce soit parce que tu es inquiète pour quelqu'un de ta famille, parce que ton collègue vient interrompre ta réflexion pour te poser une question à la con, parce que le DRH t'appelle pour te rappeler que tu n'as pas rentré le formulaire F trois-cents machin chose, cela ne loupera pas: chaque ligne de code que tu vas écrire est une occasion de plus de faire des erreurs.
- Edité par koala01 11 mai 2022 à 11:44:20
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
Demain je monte un échaffaudage, est ce que je mets les rampes de sécurité ? Je peux simplement dire "boah, je ne suis pas un p*d* je sais marcher sans trébucher quand même !! Pas besoin !"
Demain je coupe du bois avec une scie circulaire, est ce que prends le temps de sécuriser ? Je peux simplement dire "boah, je ne suis pas un p*d* pas besoin de fixer la planche, je démonte même cette coque de sécurité sous la scie qui me fait chier.... "
Pour le code, on ne risque pas sa vie, mais est ce qu'on se dit "boah, les const c'est pour les p*dés, j'en met pas !" .... et puis un jour on a un bug mystérieux, et après des heures, et des heures, et des jours de recherche, on voit qu'une fonction trèèèèèèès profonde modifiait une donnée qu'elle n'aurait pas du, et que si j'avais mis des const, ben ça n'aurait juste ... pas compilé et j'aurais corrigé en 10 secondes.
Je comprends le concept de "confiance en soi", se dire "moi je suis fort, j'ai pas besoin de sécurité, je suis trop malin pour me faire avoir...."
Et bien même avec 25 ans de programmation derrière moi, il m'arrive de faire des conneries, et le compilo ou de nombreux garde fous que je me fais me remontent rapidement le soucis. Parce que je ne suis pas infaillible, parce que je suis fatigué, parce qu'un collègue me raconte son week end, parce que pendant le confinement les enfants se chamaillaient, parce que .... parce que 1000 raisons !
Donc pour ma part, non seulement je mets des const quand il faut, mais en plus, j'ai des #ifdef FRED_CHECK qui embarquent des fonctions qui vérifient plein plein plein de trucs. ça ralentit un peu (si le define est actif) mais c'est beaucoup plus sécurisant, et dans 90% des cas, en 3 minutes j'ai le doigt sur le problème, alors que sinon ce serait une aiguille dans une botte de foin.
Pour const (et pleins d'autres choses du C++), vos explications n'auront aucun impact, à partir du moment où Jade a l'exemple de Casey, qui fait du code top trop génial sans const. "Les meilleurs devs codent sans const et font du meilleur code que vous, il suffit de ne pas se tromper".
Car je dois en avoir déjà quatre ou cinq (ou peut-être même plus) sur ce seul forum, et à peu près autant sur dvp
Fvirtman a écrit:
tu as mis combien de temps pour l'écrire ?
J'ai mis suffisamment peu longtemps à l'écrire pour que cela reste un plaisir, et avant que cela ne se transforme en corvée
Fvirtman a écrit:
J'imagine juste qu'au moment ou il clique sur envoyer, il y a une petite perte de réseau et hop, l'envoi freeze
Ris pas, ca m'est arrivé plus d'une fois ... Pas forcément sur ce forum, d'ailleurs
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
Et flute ça recommence, je suis tombée sur une vidéo où encore une fois il dit qu'il faut mesurer objectivement la qualité du code, comme par exemple le nombre de lignes, temps d'exécution, temps de compilation, combien de dépendances, combien de bugs, etc. Et on se rend compte que si on mesure ces métriques sur les logiciels "modernes" on se rend compte que ce n'est pas très bon, alors que si on faisait les choses plus simplement, tout d'un coup ça améliore une bonne partie des points cités.
Par exemple, il faut se demander si le fait d'ajouter des sémantiques d'entité/valeur apporte quelque chose, le but n'est pas de raconter une histoire théorique, mais bien de résoudre des problèmes concrets !! Si vous trouvez que telle ou telle truc apporte des bénéfices alors tant mieux, mais la plupart du temps vous suivez des pratiques sans vraiment savoir pourquoi, et la notion de "clean code" reste abstraite et pas vraiment mesurable (c'est pas parce qu'on respecte telle ou telle bonne pratique que tout d'un coup le code est objectivement mieux, surtout si le respect du principe en question impose d'alourdir le code (visiteur on pense à toi)).
Autre exemple, avoir toujours envie de compiler le code petit bout par petit bout et de faire des makefile à rallonge illisibles, comme ça "on évite de recompiler des choses qui n'ont pas changer". Premièrement, qu'est-ce qu'on s'en fout de recompiler des trucs déjà compilés ? Ce qui nous importe c'est de pas perdre trop de temps à recompiler, ça d'accord, mais si la recompilation totale est rapide, on s'en fiche du coup non ? Et deuxièmement (attachez vos ceintures ça va secouer violemment) C'EST CARREMENT PLUS RAPIDE DE TOUT RECOMPILER, c'est pour ça que les gens compilent en unity build, donc au final non seulement la phrase "on évite de recompiler des choses qui n'ont pas changer" ne sert à rien concrètement mais en plus elle est fausse puisque au final elle entraîne de découper le code en petits morceaux ce qui rend la compilation plus longue !! Et troisièmement, en recompilant tout on s'évite en plus des sales bugs de m*** liés au cache en repartant sur une bonne base à chaque fois.
"OuAi Mé uN gRoS pRojEt C LonG A cOmPiLeR"
Et bien pas du tout, déjà on peut imaginer des compilateurs modernes pensés avec les spécificités des machines modernes, et donc que ça soit rapide, et ensuite vous serez surpris du temps de compilation de centaines de milliers de lignes C++ "simples" avec peu de templates ou autre (moins d'1 min). Et en plus il est possible que beaucoup de code ne serve à rien, par exemple un OS moderne c'est 30 millions de lignes, un gros moteur plusieurs millions, parmi lesquelles combien sont réellement utilisées et pas juste trainées là par flemme de nettoyer le code ? Donc pour moi les temps de compilation ne sont pas une raison valable de vouloir "recompiler que le minimum", du moins pas en 2022, en sachant tous les inconvénients que ça apporte (complication massive du système de build, sales bugs de .o pas à jour, ...).
Je vous met aussi quelques extraits intéressants et éclairants :
"RAII is only for toy programming, your code does tons of work that it doesn't need to do. Reference counting might be fine when we don't know the lifetime of things, but 99% of the time, we know it." https://guide.handmadehero.org/code/day468/#6310
Et ici, un exemple concret de bénéfice apporté par le fait de programmer "simplement" sans rester bloqué à cause de considérations théoriques. Il a besoin d'exporter les calculs d'éclairage pour pouvoir faire des tests de performance répétables. Si il avait fait les choses d'une manière "propre" et "moderne" à base de RAII, d'allocations de partout et autre, ça aurait été un cauchemar alors que là il résout le problème (exporter l'éclairage) en 2 secondes, c'est quand même intéressant non ? https://guide.handmadehero.org/code/day591/#1879
Il y a ceux qui manipulent des trucs nuls sans même s'en rendre compte et qui s'en contentent, et des gens comme Casey qui comprennent que ça n'a pas à être mauvais et qui disent ce qui va pas dans le but que ça s'améliore (j'ai aussi une chiée d'extraits où il dit pareil pour Vulkan, je peux les poster si vous voulez)
Et vous avez une chance incroyable, abyssale, titanesque, incommensurable, car Handmade Hero est toujours en cours, donc vous pouvez aller directement lui poser des questions quand il est en live et vous verrez bien ce qu'il répondra, il vous expliquera mieux que moi
Encore des jugements à l'emporte-pièce, c'est vraiment ridicule.
>tout d'un coup ça améliore une bonne partie des points cités
Et les principaux, ils sont passés où ? La maintenabilité (et pas que par les personnes obtus tankées dans les années 80), le "time to market", le coût, etc...
A force de ne voir que ce qui l'intéresse, il ne voit pas le principal.
Si la manière old-school est la meilleur, t'en fait pas pour nous (les casse-couilles) on la connait aussi bien que lui et souvent depuis bien plus longtemps.
Qu'est qui, dans les nouvelles normes interdit de faire "à l'ancienne" ?
Rien, si on prend le temps de configurer son environnement. C'est juste que les standardisateurs sont moins obtus qu'un certain 'Hero".
>mais bien de résoudre des problèmes concrets !!
C'est quoi concret pour lui ? Parce que moi, dans la finance de marché et les satellites, bin c'était du concret.
>mais la plupart du temps vous suivez des pratiques sans vraiment savoir pourquoi,
Beaucoup d'entre nous ont des décennies d'expérience avant C++2011 et on c'est donc ce que cela voulait dire de ne pas avoir ces outils. Donc, le "savoir pourquoi", au que oui, on sait pourquoi car on n'a galérer sang et eaux parce qu'on n'avait pas ça.
>C'EST CARREMENT PLUS RAPIDE DE TOUT RECOMPILER
Il a bien de la chance, on est des nuls, mais moi, des gros projets qui prenaient des heures à compiler et même plusieurs minutes pour un simple update d'un fichier, c'était ma vie, et c'était bien avant C++2011 ou des templates.
S'il n'a que des projets de "bisounours", qu'il garde ces conseils de Popples pour lui.
>liés au cache en repartant sur une bonne base à chaque fois.
Faux problème qu'un peu de méthodologie règles sans soucis.
>ensuite vous serez surpris du temps de compilation de centaines de milliers de lignes C++ "simples"
GG, maintenant, avec des code base de plusieurs millions de lignes qui font conçus pour faire de "vraies" choses, ça donne quoi ?
Déjà qu'il faudra des semaines supplémentaires pour faire les choses, et uniquement par un "héro" (enfin, un boulet d'étranglement), il faut combien de compilations putativement rapide pour compenser ce délai ?
>Et en plus il est possible que beaucoup de code ne serve à rien, par exemple un OS moderne c'est 30 millions de lignes,
Non, c'est vrai, les outils de couverture de tests/détection de code mort, c'est de la science-fiction, putain d'appel à l'ignorance.
Si tu veux qu'on te prenne au sérieux, commence par choisir tes combats.
Parce que là, avec cet argumentaire tout pourri dans tous les sens, c'est clairement du trollisme de bas étage.
La seule fois où t'as répondu avec un cas concret, tes conclusions étaient fausses.
On se plante tous, mais le mille-feuille argumentatif, c'est pour les conspi., pas pour le développement efficace.
Donc, un cas concret SVP.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
on va certainement faire des erreurs qu'il faut prévenir, mais imaginez que ce ne soit pas le cas
Je n'avais pas fait attention à cette pépite. La gestion des erreurs n'est pas nécessaire, il suffit juste de ne pas faire d'erreur. Facile. Pourquoi on n'y avait pas pensé avant ??? Là, je reconnais qu'on est nul, la solution était toute simple !!!
C'est tellement con comme remarque.
🤣🤣🤣🤣 pourquoi mourir d'une maladie, il suffit de ne pas tomber malade
Moi connement je lis le pavé hier soir et je vois des liens je me dis "ah bah je vais pouvoir regarder les exemples de code avec et sans RAII demain et comparer objectivement les deux codes". A la place je trouve un narcissique en train de se tripoter le sifflet devant un miroir, déception.
Genre :
JadeSalina a écrit:
Et ici, un exemple concret de bénéfice apporté par le fait de programmer "simplement" sans rester bloqué à cause de considérations théoriques. Il a besoin d'exporter les calculs d'éclairage pour pouvoir faire des tests de performance répétables. Si il avait fait les choses d'une manière "propre" et "moderne" à base de RAII, d'allocations de partout et autre, ça aurait été un cauchemar alors que là il résout le problème (exporter l'éclairage) en 2 secondes, c'est quand même intéressant non ? https://guide.handmadehero.org/code/day591/#1879
Elle est où la comparaison avec la "version hyper compliquée que les gens de modern-C++ font parce qu'ils sont mauvais contrairement à moi qui suit grand beau et fort" ? Non parce que c'est bien gentil d'expliquer que ce serait plus compliqué mais en fait, il ne montre absolument pas en quoi.
JadeSalina a écrit:
"RAII is only for toy programming, your code does tons of work that it doesn't need to do. Reference counting might be fine when we don't know the lifetime of things, but 99% of the time, we know it." https://guide.handmadehero.org/code/day468/#6310
Oh bah merde alors ! Si seulement on avait un pointeur intelligent et des conteneurs qui ne font pas de référence counting pour gérer les lifetime ?! Dude, ça existe putain, ça s'appelle unique_ptr et littéralement tous les autres conteneurs de la SL. Et alors l'argument de "ouais mais en fait ces machins ils font plein de trucs qui ne sont pas utiles", franchement, le mec est beaucoup plus incompétent que je le pensais. Pour expliquer que unique_ptr fait plein de trucs inutiles, il ne faut jamais avoir ouvert l'assembleur généré par un code qui l'utilise.
Quand tu veux améliorer les choses, tu démontres que ce que tu dis est vrai en mettant côte à côte des choses qui font la même tâche et de façon à ce qu'on puisse les comparer clairement et déterminer si oui ou non c'est vrai. Si tu produis des algos incroyablement plus performants que ce que font les autres acteurs du domaine, tu publies tes travaux pour que d'autres puissent vérifier que ce que tu dis est vrai et que d'autres puissent améliorer leur propre situation. Tu te tripotes pas en vidéo.
Pour le unique_ptr, je l'avais programmé moi même de façon simple à l'époque :
une classe avec le constructeur par recopie et l'opérateur = en private pour éviter la recopie, et tout le reste des méthodes inline
Autrement dit, au niveau assembleur la même chose qu'un pointeur nu, et c'est juste le compilateur qui vérifiait que je ne faisais pas de copie.
Donc a l'exécution, comme un pointeur nu....
Je commence sérieusement à me demander si ce "Casey" est si fort que ça.
Au fait, tu dis toi même (JadeSalina) qu'il est un gros raleur. Ce genre de mec est toxique dans une équipe. Si tu es intégriste dans le monde de la programmation, tu pourris une boîte. Car les autres ne programmeront jamais tous de la même manière.
"Et vous avez une chance incroyable, abyssale, titanesque, incommensurable, car Handmade Hero est toujours en cours, donc vous pouvez aller directement lui poser des questions quand il est en live et vous verrez bien ce qu'il répondra, il vous expliquera mieux que moi" Et quand tu quitte ta secte ?
tu te lis sérieusement ? une chance "incroyable, abyssale, titanesque, incommensurable", t'aurais dit que c'est Dieu , ça aurait été pareil...
sans parlé que pour argumenter, tu as mis 5 liens sur casey...
Vraiment à force ,c'est même plus marrant ,c'est inquiétant. Et sérieusement tu devrais moins t'inquiéter sur la bonne prog en C++ , mais sur ton rapport avec Casey , parce que moi à force, je trouve ça ultra malsain... La vie est quand même un peu plus importante que des guerres de chapelle du C++ (si je veux être sympa est dire que Casey à aussi des opinions "valable") , et surtout ,je pense pas qu'il faut aller dans une relation malsaine,dérangeante pour apprendre du C++.
Donc ,tu ne donne que l'inverse de ce que tu veux, quand tu parle de casey comme un Dieu ou un gourou , non ce genre de relation ne fait ni vendre , ni rêver !
Elle est où la comparaison avec la "version hyper compliquée que les gens de modern-C++ font parce qu'ils sont mauvais contrairement à moi qui suit grand beau et fort" ? Non parce que c'est bien gentil d'expliquer que ce serait plus compliqué mais en fait, il ne montre absolument pas en quoi.
Oui il ne montre pas en quoi mais il suffit de regarder la plupart des projets C++ ils ont une organisation super complexe qui aurait rendu une sérialisation du truc plus dur, avec plus de code à écrire, peut être devoir utiliser une lib en plus, etc, alors que là vu qu'il stocke les choses simplement, il peut directement copier la mémoire dans un fichier et c'est bon. Et c'est ce genre de choses auquel je fais référence quand je parle de "lumière de Casey" ou autre, c'est que on peut arriver à de supers trucs d'une manière super simple quand on ne se complique pas la vie inutilement.
J'essaie de faire un mélange de vous et de Casey et j'arrive à une conclusion que oui ça peut aider d'ajouter de la sémantique pour éviter certaines erreurs, de suivre des pratiques standards etc, mais c'est pas forcément ce qu'on veut faire tout le temps.
Bien entendu que c'est ignoble de faire un malloc et de renvoyer un pointeur qui va on sait pas où, du coup ils se sont dit qu'il fallait renvoyer un unique_ptr comme ça on sait à qui ça appartient. Donc on en arrive à ce que je veux dire, est-ce que c'est bien LA solution ?
en particulier que du code C se retrouve plus léger que l'équivalent C++, on ne sait pas pourquoi, qu'on peut réfléchir à de meilleurs manières de gérer les ressources (et pas seulement un objet = une ressource) et que le C++ de part sa complexité détourne la réflexion du problème concret, vers des problèmes théoriques qui la plupart du temps n'aident même pas à résoudre le problème.
Vous noterez aussi qu'il n'y a pas que le C/C++ dans la vie, et que d'autres langages introduisent aussi de nouvelles sémantiques et d'autres façons de penser (cf Rust)
->Oui il ne montre pas en quoi mais il suffit de regarder la plupart des projets C++ ils ont une organisation super complexe qui aurait rendu une sérialisation du truc plus dur, avec plus de code à écrire, peut être devoir utiliser une lib en plus, etc, alors que là vu qu'il stocke les choses simplement, il peut directement copier la mémoire dans un fichier et c'est bon. Et c'est ce genre de choses auquel je fais référence quand je parle de "lumière de Casey" ou autre, c'est que on peut arriver à de supers trucs d'une manière super simple quand on ne se complique pas la vie inutilement
D'une manière super simple "peut etre" maintenable ( avec le temps, l'ajout de fonctionnalités...) j'en doute, propre à lire j'en doute.
->
J'essaie de faire un mélange de vous et de Casey et j'arrive à une conclusion que oui ça peut aider d'ajouter de la sémantique pour éviter certaines erreurs, de suivre des pratiques standards etc, mais c'est pas forcément ce qu'on veut faire tout le temps
A aucun moment on ne dit qu'il est obligatoire de suivre les standards, on dit qu'il faut choisir la bonne solution selon les cas les particularité ect et il s'avère que la plupart du temps les standards dont tu parles sont meilleurs.
-> Le problème c'est que quand on commence à mettre un peu de sémantique (ah tiens ce truc est pas censé être public, ah tiens ce truc n'est pas censé changer, ah tiens ce truc doit pas être copiable) au lieu de réfléchir au problème lui même, on arrive potentiellement dans un trou à rat où on se retrouve bloqué parce qu'il y a trop de complexité (comme dans l'exemple que j'ai donné où il copie juste un bloc mémoire et c'est bon alors quand dans un truc C++ classique il y aurait des objets, contenant des shared_ptr, etc, qui aurait rendu la sérialisation plus difficile à faire).
Je me rends compte que tout ce que tu decris c'est pour essayer de passer les étapes du code enfait, faire un foure tout que tu vas placer quelque part et avec lequel tu te demerdes après ou explique mieux si je ne comprends pas
->
sais que c'est dur à comprendre, mais il faut se rendre compte que moins de code = plus de simplicité, plus de performance, plus de flexibilité, etc, et NOOOOON il ne suffit pas de faire des trucs "comme en C" dégueulasse des années 80, sinon on aurait pas inventé C++. Le truc c'est que C++ prend du C dégueulasse et "corrige" le problème, mais en faisant la même chose !! (c'est juste qu'elle est cachée au programmeur) (cf tous les exemples de cours C++ qui introduisent les pointeurs intelligents)
Haha moins de code = plus de simplicité- plus de performance plus de flexibilité du grand n'importe quoi.
Si je te prend un exemple vraiment bête mais c'est au niveau de la phrase
tu as 1000 if else if, tout ces if else if peut etre emboîté dans des ternaires ce qui te donnera techniquement moins de code, à lire pour le dev qui va venir faire une mise à jour c'est impossible ou prend trop de temps, à lire pour toi meme qui viens des mois après meme chose. Surtout en sachant que les compilateurs feront le boulot et donneront des résultats tres similaires à la fin.
Des trucs dégueulasse comme en c, ce n'est pas pour rien que c++ a été inventé et évidemment le code c est dégueulasse les librairies et autre ecrits en c pour des languages comme java python ou autres.
Il est facile de sortir des critiques vide de sens sur des choses que des gens bien plus qualifiés ont passé des années à élaborer et a faire evoluer. La solution serait de creer le Casey sa reglerait tout
Le problème c'est que quand on commence à mettre un peu de sémantique (ah tiens ce truc est pas censé être public, ah tiens ce truc n'est pas censé changer, ah tiens ce truc doit pas être copiable) au lieu de réfléchir au problème lui même, on arrive potentiellement dans un trou à rat où on se retrouve bloqué parce qu'il y a trop de complexité (comme dans l'exemple que j'ai donné où il copie juste un bloc mémoire et c'est bon alors quand dans un truc C++ classique il y aurait des objets, contenant des shared_ptr, etc, qui aurait rendu la sérialisation plus difficile à faire).
Encore une fois, tu supposes beaucoup de choses, notamment :
que réfléchir à la sémantique d'une classe c'est coûteux,
que se demander comment avoir une bonne API c'est un coût sans retour sur investissement,
qu'une personne qui aurait fait la même chose que ce que Casey présente l'aurait fait avec des shared_ptr et une usine à gaz complexe.
Or, 1. c'est pas coûteux, 2. en préservant les bons invariants, on évite des bugs et c'est trivial de rendre quelque chose public s'il était précédemment privé donc il n'y a pas de coût à mettre les choses initialement privé, 3. rien ne dit que ce serait le cas.
JadeSalina a écrit:
Je sais que c'est dur à comprendre, mais il faut se rendre compte que moins de code = plus de simplicité, plus de performance, plus de flexibilité, etc,
Évite de débarquer en croyant nous apprendre des trucs, personnellement je doute très fortement que tu ais bosser sur des projets utilisés dans la vie par des utilisateurs qui en ont vraiment besoin. Tout le monde sait que moins de code, c'est un avantage. C'est précisément la raison pour laquelle :
tout réécrire from scratch sans utiliser de bibliothèque c'est stupide, ça fait augmenter la quantité de code à produire et maintenir,
se palucher de la gestion de mémoire manuelle + de la gestion des erreurs sans exceptions est casse gueule parce que ça impose justement d'ajouter du code pour ça.
Les gens ne font pas des gros codes parce que ça les amuse d'avoir une grosse base de code. Ils font des gros codes parce que c'est nécessaire pour leur application métier et quand ils peuvent en virer, ils ne se gênent pas pour le faire.
L'article que tu cites passe à côté de l'essentiel avec le RAII. Le point n'est pas de savoir s'il est possible d'avoir une gestion propre de la mémoire dans un langage comme C. Ça l'est. On le sait. La question c'est de savoir s'il est possible d'avoir une gestion telle que l'on obtient des garanties fortes que la gestion des ressources va être effectuée. Et ça :
en C, on ne l'a pas, et même des outils extrêmement avancés du domaine sont encore incapables d'amener ce genre de garanties,
en C++, le problème de le faire à la main est plus difficile parce que pour éviter du boiler-plate de gestion d'erreurs à tous les étages, on utilise les exceptions.
Dans certains domaines d'applications, la gestion des erreurs est linéaire, donc on n'a pas besoin d'une mécanique d'exceptions. Dans d'autres, la complexité de gestion des erreurs est inhérente au système et le code de retour devient inutilisable (d'où le passage aux exceptions). Les autres solutions (monades des erreurs) nécessitent un outillage spécifique au langage pour éviter d'arriver à du code illisible.
zvheer a écrit:
tu as 1000 if else if, tout ces if else if peut etre emboîté dans des ternaires ce qui te donnera techniquement moins de code
Le problème c'est que quand on commence à mettre un peu de sémantique (ah tiens ce truc est pas censé être public, ah tiens ce truc n'est pas censé changer, ah tiens ce truc doit pas être copiable) au lieu de réfléchir au problème lui même, on arrive potentiellement dans un trou à rat où on se retrouve bloqué parce qu'il y a trop de complexité (comme dans l'exemple que j'ai donné où il copie juste un bloc mémoire et c'est bon alors quand dans un truc C++ classique il y aurait des objets, contenant des shared_ptr, etc, qui aurait rendu la sérialisation plus difficile à faire).
Encore une fois, tu supposes beaucoup de choses, notamment :
que réfléchir à la sémantique d'une classe c'est coûteux,
que se demander comment avoir une bonne API c'est un coût sans retour sur investissement,
qu'une personne qui aurait fait la même chose que ce que Casey présente l'aurait fait avec des shared_ptr et une usine à gaz complexe.
Or, 1. c'est pas coûteux, 2. en préservant les bons invariants, on évite des bugs et c'est trivial de rendre quelque chose public s'il était précédemment privé donc il n'y a pas de coût à mettre les choses initialement privé, 3. rien ne dit que ce serait le cas.
+1, le seul truc couteux ici, c'est de prendre des habitudes modernes, et c'est un travail que l'on ne peut pas faire à ta place.
JadeSalina a écrit:
Je sais que c'est dur à comprendre, mais il faut se rendre compte que moins de code = plus de simplicité, plus de performance, plus de flexibilité, etc,
Évite de débarquer en croyant nous apprendre des trucs, personnellement je doute très fortement que tu ais bosser sur des projets utilisés dans la vie par des utilisateurs qui en ont vraiment besoin. Tout le monde sait que moins de code, c'est un avantage. C'est précisément la raison pour laquelle :
tout réécrire from scratch sans utiliser de bibliothèque c'est stupide, ça fait augmenter la quantité de code à produire et maintenir,
se palucher de la gestion de mémoire manuelle + de la gestion des erreurs sans exceptions est casse gueule parce que ça impose justement d'ajouter du code pour ça.
Les gens ne font pas des gros codes parce que ça les amuse d'avoir une grosse base de code. Ils font des gros codes parce que c'est nécessaire pour leur application métier et quand ils peuvent en virer, ils ne se gênent pas pour le faire.
L'article que tu cites passe à côté de l'essentiel avec le RAII. Le point n'est pas de savoir s'il est possible d'avoir une gestion propre de la mémoire dans un langage comme C. Ça l'est. On le sait. La question c'est de savoir s'il est possible d'avoir une gestion telle que l'on obtient des garanties fortes que la gestion des ressources va être effectuée. Et ça :
en C, on ne l'a pas, et même des outils extrêmement avancés du domaine sont encore incapables d'amener ce genre de garanties,
en C++, le problème de le faire à la main est plus difficile parce que pour éviter du boiler-plate de gestion d'erreurs à tous les étages, on utilise les exceptions.
Dans certains domaines d'applications, la gestion des erreurs est linéaire, donc on n'a pas besoin d'une mécanique d'exceptions. Dans d'autres, la complexité de gestion des erreurs est inhérente au système et le code de retour devient inutilisable (d'où le passage aux exceptions). Les autres solutions (monades des erreurs) nécessitent un outillage spécifique au langage pour éviter d'arriver à du code illisible.
Je n'écoute pas, je constate: que préfères-tu ? ceci:
Perso, mon choix est fait. Garde bien en tête que le 1er but d'un code source est d'être lu et compris par "quelqu'un d'autre que toi". Le coté fonctionnel n'arrive qu'en 2e position, quand à l'efficacité, elle est loin dans la file d'attente.
× 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.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Si vous ne trouvez plus rien, cherchez autre chose.
Discord NaN. Mon site.
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Discord NaN. Mon site.
yasakani no magatama
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
yasakani no magatama
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C