mais quand même vous vous rappelez que le but premier c'est d'avoir un programme qui fait ce qu'on veut ?
En vrai, le but premier est juste d'avoir un salaire. Apres, que ca marche bien ou pas, tant qu'on est payé, c'est pas notre problème. Les gens n'ont qu'a acheter des plus gros ordinateurs.
JadeSalina a écrit:
Je sais que vous aimez passer vos vacances à TheoryLand
Cela dit, dans cette discussion, il y a des pros qui bossent et font des programmes concrets qui tournent. Et une personne qui parle beaucoup mais qui ne veut pas aller chercher un boulot et faire des vrais projets.
N'hésite pas a nous envoyer des cartes postales de tes vacances a TheoryLand.
Je bosse dans un domaine ou l'optimisation est primordiale (très calculatoire).
Et pourtant, nous faisons du code lisible, car il faut le maintenir, corriger les soucis, l'améliorer, etc....
Mais surtout après énormément de tests pour gagner du temps, j'ai remarqué que beaucoup d'optimisations qui pourrissent le code n'apportent quasiment rien.... Voir rien du tout.
En optimisation, il faut distinguer les zones critiques : importantes à optimiser, et les autres dont on se fout.
Si certaines fonctions critiques très très localisées peuvent être rendues un peu moins lisibles pour gagner du temps, 95% du code n'a aucun intérêt à être pourri de la sorte.
Pinaise l'encre coule ! Faut que je revienne là-dessus :
Lynix a écrit:
La seule bonne raison de répondre et d'expliquer est d'éviter que d'autres personnes lisant ces messages ne tombent dans le même délire. Une alternative serait une action de la modération (bannissement / fermeture du moindre topic du genre).
Perso, je considère que c'est une bonne chose justement, ça fait un topique très informatif avec des boutades en prime. Je bite pas grand-chose à la programmation (j'en suis à faire des print() en py), mais je dévore la discussion comme un nouveau Tolkien !
Côté modération, tant que ça ne déraille pas hors charte, ça passe. Ce n'est pas le premier profil à avoir ce genre d'effet dans un forum, ça ne sera pas le dernier, et en soi : on ne va pas ban quelqu'un pour avoir posé des questions que certains jugent mal informées.
Et vous préférez un code lisible à un code qui fonctionne ?? koala a dit la même chose, j'ai fait semblant de ne pas avoir vu. Là pour le coup je comprend pas, il vaut mieux avoir un code "pas super clean" mais qui fait le taff, que d'avoir un code magnifique
Et la, tu oublies une composante importante du travail de développeur: La maintenance et les coûts qui lui sont associés. Car le développement, c'est pas gratuit, et ton code "pas super clean" va demander de nombreux jours de travails à ceux qui seront en charge de le maintenir, le faire évoluer, le tester ect ... Et je peux te jurer qu'a grand coup de 500+€ par jour et par personne, ça chiffre extrêmement vite.
Alors, être propre et optimiser plus tard (si et seulement si on se rend compte que l'on est pas dans les tolérances acceptables), c'est un grand OUI.
Si on a envie d'avoir un beau code avec des belles classes abstraites, par exemple avoir un Object qui peut être une Sphere, un Plane,
un "God object", quelle hérésie...
JadeSalina a écrit:
(..) des belles classes abstraites,[...] où il suffira de redéfinir les tests d'intersections, etc, sans dupliquer de code. Oui c'est joli en terme de code,
Tu confonds tout, "ma belle"! Ce n'est pas le fait de travailler avec de "belles classes abstraites" qui rend le code "joli". Du moins, pas en C++.
C'est peut-être vrai pour d'autres langages qui obligeront toutes tes classes à hériter (de manière implicite qui plus est) d'une classe de base Object, pour satisfaire à certains besoins qu'ils ont eux-même créés. Mais ce n'est absolument pas le cas en C++, où la première réaction sur du code récent sera de tirer à boulets rouges sur ce genre de conception.
JadeSalina a écrit:
(...) sans dupliquer de code.
Sais tu qu'il existe des dizaines de solutions pour éviter d'avoir à dupliquer du code? Bon, j'exagère surement un peu en parlant de dizaines au pluriel. Il se peut même que j'exagère un peu en parlant d'une dizaine au singulier...
Ce qui est important de comprendre, c'est que toutes ne font pas forcément appel à des fonctions membres virtuelles ou aux templates, mais que toutes seront beaucoup plus faciles à mettre en oeuvre à partir du moment où le SRP est effectivement respecté.
JadeSalina a écrit:
(...)la vérité c'est que c'est juste moins performant, le résultat est donc moins bon,
Pourquoi le résultat serait-il ** forcément ** "moins bon" parce que "moins performant"? Pourquoi serait-ce forcément un problème d'obtenir un résultat identique en 0.1 secondes au lieu de l'obtenir en 0.03 secondes dans certaines situations?
JadeSalina a écrit:
et le client qui utilise le résultat s'en fiche de savoir comment c'est codé, il veut un truc qui marche bien et qui rame pas, donc c'est dommage de défavoriser le client au profit du programmeur.
Non, ce que veut l'utilisateur, c'est avant tout quelque chose qui fonctionne, qui donne le résultat espéré sans se planter.
Il se fout pas mal d'avoir une voiture capable de rouler à 240 km/h, si un problème dans la direction l'assure de finir dans le premier mur qu'il rencontrera une fois sur deux! A ce rythme là, il préfère encore une bonne vieille 2CV ou R4, qui atteint difficilement les 98 km/h (en descente et avec le vent dans le dos), mais qui lui garanti d'arriver "sain et sauf" à destination.
Or, le premier impératif pour avoir quelque chose qui marche, c'est de pouvoir le corriger au besoin. Et pour pouvoir corriger quelque chose, il faut pouvoir le lire.
Une fois que l'on a quelque chose qui marche, alors, on peut espérer obtenir quelque chose qui fonctionne "plus rapidement", pour autant que la vitesse actuelle représente effectivement un problème.
J'ai entendu parler récemment d'un projet (qui n'était pas écrit en C++) développé par une équipe de scientifiques qui savaient programmer mais qui ne connaissaient rien au développement informatique.
Ce projet mettait un mois entier à leur fournir les résultats attendus, et ils en étaient très contents, pour ne pas dire fiers.
Jusqu'au jour où un autre scientifique, qui comprenait "un peu mieux" ce qu'est réellement le développement informatique est arrivé dans l'équipe.
Ce type n'a pas été voir du coté de l'assembleur généré (et pour cause, on parle d'un langage interprété)
Ce type n'a pas décidé de changer de langage (et pour cause, cela aurait provoqué un tollé général).
Ce type s'est "contenté" de revoir quelques algorithmes "bien choisi" et de les optimiser. Avec un résultat inouï: alors que, juste avant, ils auraient attendu le résultat de leur simulation pendant un mois entier, ils l'ont obtenues en à peine trois jours.
90% du temps est perdu dans 10% du code
Bien sur, il s'agit d'une approximation "à la grosse louche". Bien sur, il se peut même que les proportions varient en fonction des sources (tu liras parfois des proportions de 80/20, de 70/30 ou parfois même de 60/40).
Ce qui importe, c'est que les gains que tu pourrais espérer en optimisant la majeure partie de ton code sont tout simplement marginaux par rapport à ceux que tu peux espérer en n'optimisant qu'une "infime partie" soigneusement sélectionnée.
Mais plus encore, tu obtiendras de bien meilleurs gains en optimisant l'algorithme, en optimisant la logique avant d'essayer "de baiser" le compilateur / l'interpréteur à coup de hacks et d'assembleur.
Seulement, encore une fois, pour être en mesure d'optimiser l'algorithme, pour pouvoir optimiser la logique, il faut être en mesure de la comprendre à la lecture du code.
JadeSalina a écrit:
a comparé le style orienté objet qui est "beau" et "propre" avec un style orienté données,
Tu oublie juste de préciser qu'il a fait cette comparaison dans un domaine bien particulier, qui est d'ailleurs indiqué dans le titre de la conférence: le “Path Tracing".
Tu zappes en outre complètement que personne ici n'a jamais prétendu que l'orienté objet au sens propre -- comprend: celui qui incite à se poser la question du LSP afin d'assurer la substituabilité permettant de mettre en place le polymorphisme d'inclusion -- était "la solution miracle".
Certains -- des commerciaux pour la plupart -- l'on prétendu par le passé.
D'autres continuent même à le prétendre pour soutenir leur langage de prédilection parce qu'il ne leur autorise au final que ce paradigme.
Ces gens n'ont décidément rien compris. Car l'orienté objet à proprement parler n'est rien de plus qu'une technique particulière, qui, à l'instar de toutes les autres, présente certes de sérieux avantages, mais également de sérieux inconvénients.
D'autres personnes pourraient croire que l'orienté objet a juste pour objectif de permettre la présence de fonctions membres dans les classes, sans même poser la question de la possibilité de l'héritage publique ni celle d'en redéfinir le comportement dans les classes dérivées.
C'est peut-être plus proche, tout compte fait, de la manière dont le paradigme orienté objet est présenté en C++, car une classe ne doit pas forcément hériter d'une autre, car les fonctions membres ne sont pas forcément virtuelles.
Mais cette approche ne fait que mettre en place des outils permettant de faciliter l'encapsulation. Certes très intéressant, mais cela n'a que peu à voir avec l'orienté objets. Car l'encapsulation est un principe connu depuis bien avant l'arrivée de l'orienté objets
JadeSalina a écrit:
n'est pas ce qu'il y a de plus performant sur les architectures actuelles de nos PC, qui préfèrent manipuler des données en masse (https://www.youtube.com/watch?v=HG6c4Kwbv4I)
Si tu n'étais pas aussi casse ... bonbons (voilà que tu me ferais devenir vulgaire, tiens) en étant persuadée d'être la seule à connaitre la vérité et que nous sommes tous des connards incompétents aussi psychorigides que toi, j'en pisserais presque de rire...
Car, figure toi que, à l'époque où cette conférence (excellente, il faut bien l'avouer) a été donnée, cela ne fait ... Bah, qu'une quinzaine d'années (voire plus) que l'on crie que l'orienté objet n'est pas la panacée, que dans certaines situations il est préférable d'avoir une approche orientée données, et que le C++ est justement génial pour cela.
D'ailleurs, si tu vas aux alentours du timestamp de 40:00, tu verras ses conclusions. Hé bien, figure toi que c'est ce que l'on rappelle à longueur d'année depuis ... je ne saurais même plus dire quand, tiens.
Au passage, si tu vas directement aux alentours du timestamp 42:50, tu remarqueras que ses tests montrent clairement que l'orienté objet s'avère plus rapide avec son "suzanne"...
Cela met en évidence le point que tu n'arrives de toutes évidence pas à admettre: une solution peut être "miraculeuse" dans une situation donnée et "catastrophique" dans d'autres
La seule chose étant que nous avons un discours peut être un peu moins orienté vers un problème spécifique qui dit:
Chaque technique présente certains avantages dans une situation donnée. Chaque technique présente également des inconvénients dans une situation données. C++ nous permet de choisir la meilleure solution en fonction de la situation à laquelle on est confronté. Le plus difficile est de choisir "la bonne technique" pour le "bon usage", pour la "bonne situation"
De même, si tu tires jusqu'aux alentours du timestamp 44:33, tu remarqueras que le nombre d'instructions a finalement beaucoup moins d'impact que les mauvaises prédictions de branches: le programme est plus rapide avec l'OO, alors qu'il fait exécute presque deux fois plus d'instructions. Le seul truc étant qu'il y a à peu près 20 fois moins d'erreurs de prédiction
Enfin, ce que je retiendrai particulièrement de ce qui se dit aux alentours du timestamp 52:00, c'est que les tentatives de micro optimisations (on parle d'éviter les mauvaises prédictions de branches en remplaçant les OU logiques par des OU binaires) ne seront réellement intéressantes que dans une situation donnée : nous aurions pu croire que cela aurait produit un résultat très similaire partout, mais ce n'est clairement pas le cas: dans certaines circonstances, ce qui est sensé rendre le code plus rapide a en réalité comme résultat de le ralentir. Bizarre, non?
Or, c'est justement ce que l'on te répète à longueur de discussions.
- Edité par koala01 12 juillet 2022 à 19:41:05
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
> chercher à avoir un code lisible en premier lieu ferme des possibilités d'optimisation
Faux, ça permet notamment de s'y retrouver pour savoir comment optimiser.
Il faut qu'on comprenne bien de quoi on parle, si on code à la rache et qu'on met tout dans la même fonction, qui se retrouve à faire 3500 lignes avec du code dupliqué de partout, c'est sûr qu'il faudrait commencer par nettoyer ce bazar avant d'entreprendre le moindre truc, car sinon on a toutes les chances de tout péter en touchant à ce genre de bouse. Donc de ce point de vue, +1 pour la lisibilité.
dragonjoker a écrit:
Faux, le cloisonnement n'a aucun impact sur le performances, et permet d'isoler les bouts de code qui sont lents.
Si ce que vous appelez cloisonnement c'est faire des classes isolées avec leur petites méthodes, etc, alors oui ça n'a pas d'impact direct !! Et tant mieux d'ailleurs, comme je vous l'ai dit avant, je préfère le style "méthode" au style "fonction qui prend en paramètre un objet". Et comme je l'avais aussi dit avant, dans ce document (https://www.agner.org/optimize/optimizing_cpp.pdf) on retrouve le coût de chaque fonctionnalité de C++, et comme attendu, les méthodes n'ont aucun impact sur les perfs par rapport à une fonction normale.
Maintenant, le cloisonnement ça peut amener à penser à "un truc isolé à la fois", et ne pas avoir une "vue d'ensemble". Qu'est ce qui vous dit que ça serait pas mieux de combiner une partie de la classe A avec la classe B, pour optimiser par exemple d'éventuels coûts de passage de messages entre les 2, si il y en a ? Donc oui ça permet d'optimiser chaque truc individuellement, mais pas forcément le programme global...
gbdivers a écrit:
En vrai, le but premier est juste d'avoir un salaire. Apres, que ca marche bien ou pas, tant qu'on est payé, c'est pas notre problème. Les gens n'ont qu'a acheter des plus gros ordinateurs.
En optimisation, il faut distinguer les zones critiques : importantes à optimiser, et les autres dont on se fout.
Oui je ne dis pas le contraire, si on passe 2 jours à optimiser un truc, idéalement on aimerait que ça serve à quelque chose. Et toutes les optimisations ne se valent pas, remplacer par exemple un "a % n" par un "a & (n - 1)" car on sait que "n" est une puissance de 2, c'est quelque chose que le compilateur fera tout seul, pas la peine de pourrir le code pour ça. Mais le compilateur ne pourra pas trop aider sur les optimisations plus complexes qui nécessitent par exemple de mettre des trucs en cache, réorganiser les données en mémoire, etc.
bacelar a écrit:
>le client qui utilise le résultat s'en fiche de savoir comment c'est codé, il veut un truc qui marche bien et qui rame pas
LOL, il est optimisé comment le jeu le plus rentable de tout les temps : "Minecraft" ???
A LA TRUELLE.
Et bien ça c'est très dommage, car je voulais jouer à minecraft sur un vieux ordi portable, bah ça tournait à 15 fps, du coup j'ai pas pu jouer. Donc si le code était "optimisé" et "moins lisible", ça aurait été bénéfique pour moi (en supposant qu'ils ait les ressources pour le faire, évidemment que si c'est pour qu'ils passent 30 ans à optimiser ça vaut pas forcément le coup, il vaut mieux avoir un produit raisonnable en un temps raisonnable que pas de produit du tout, mais le mieux du mieux serait d'avoir un très bon produit et rapidement )
Deedolith a écrit:
Alors, être propre et optimiser plus tard (si et seulement si on se rend compte que l'on est pas dans les tolérances acceptables), c'est un grand OUI.
Ça dépend de ce qu'on appele des "tolérances acceptables". Casey avait eu des conversations avec Microsoft au sujet de la lenteur de Visual Studio, et ils lui ont répondu que le temps de démarrage qu'ils visaient c'était 10 secondes sur la plupart des machines. Pour moi 10 sec pour commencer à dev, c'est de la folie, même si on le lance qu'une fois le matin, ça fait toujours 10 sec de perdu. Visual Studio 6 sur un Pentium 4 et 512 Mo de RAM est beaucoup plus rapide que Visual Studio 2022 sur un i9 moderne !! https://www.youtube.com/watch?v=GC-0tCy4P1U&t=2108s
"oUi Mé yA mOiNs dE fOncTioNnaLités"
Bah franchement je préfère un truc rapide moins complet qu'un gros truc lent, surtout quand je n'utilise pas les dites fonctionnalités !!
"Tenez ce magnifique routeur avec Wifi 6 AX 4x4 5GHz 5400Mbps avec éclairage RGB pour seulement 1500€"
Alors déjà je branche mon pc par cable, j'ai même pas la fibre et le routeur je le met sous un meuble planqué donc je m'en fou du RGB !! Donc je préfère largement un truc à 50€ qui fait juste ce que je lui demande, plutôt que de payer un truc super cher (ou euros ou en temps perdu en lenteur) qui apporte des trucs qui me servent pas !
koala01 a écrit:
JadeSalina a écrit:
Si on a envie d'avoir un beau code avec des belles classes abstraites, par exemple avoir un Object qui peut être une Sphere, un Plane,
un "God object", quelle hérésie...
Complètement d'accord, j'ai appelé ça Object pour aller plus vite, mais ça devrait s'appeler "Shape" ou "Hittable" ou un truc comme ça (l'exemple que je donne c'est pour pouvoir calculer des intersections entre un rayon et des objets, qui peuvent être de différents types (et donc avoir un calcul d'intersection différent, qu'on override pour chacun, ce qui est bien une approche "orientée objet"))
koala01 a écrit:
JadeSalina a écrit:
(..) des belles classes abstraites,[...] où il suffira de redéfinir les tests d'intersections, etc, sans dupliquer de code. Oui c'est joli en terme de code,
Tu confonds tout, "ma belle"! Ce n'est pas le fait de travailler avec de "belles classes abstraites" qui rend le code "joli". Du moins, pas en C++.
C'est peut-être vrai pour d'autres langages qui obligeront toutes tes classes à hériter (de manière implicite qui plus est) d'une classe de base Object, pour satisfaire à certains besoins qu'ils ont eux-même créés. Mais ce n'est absolument pas le cas en C++, où la première réaction sur du code récent sera de tirer à boulets rouges sur ce genre de conception.
Ce que je qualifiais de joli, c'est surtout d'avoir un algo codé quelque part, qui voit passer des objets, et qui demande pour chacun de calculer l'intersection. Du coup les "Shapes" n'ont qu'à override la fonction virtuelle sans se demander comment l'algo général fonctionne, c'est bien comme ça que vous auriez fait en orienté objet n'est ce pas ? Vous voulez quand même pas que je vous sorte ce genre de chose :
Pourquoi le résultat serait-il ** forcément ** "moins bon" parce que "moins performant"? Pourquoi serait-ce forcément un problème d'obtenir un résultat identique en 0.1 secondes au lieu de l'obtenir en 0.03 secondes dans certaines situations?
Oui oui ça dépend du gain, si on s'en rend pas compte c'est pas forcément pertinent
koala01 a écrit:
Mais plus encore, tu obtiendras de bien meilleurs gains en optimisant l'algorithme, en optimisant la logique avant d'essayer "de baiser" le compilateur / l'interpréteur à coup de hacks et d'assembleur.
Oui les optimisations algorithmiques (que le compilateur peut difficilement faire tout seul) sont celles qui atomisent toutes les micro optimisations qu'on peut faire, j'ai presque envie de dire "sans maitrise, la puissance n'est rien".
A ce sujet ils avaient prévu de cracker RSA sur je sais plus combien de bits vers les années 2000 où un truc comme ça, en se basant sur la loi de Moore, mais finalement ils ont cracké le truc des décennies plus tôt que prévu grâce à un meilleur algo.
Et au sujet de "baiser" le compilateur, j'avais vu une conférence où le mec essayait d'optimiser un calcul à coup de bithacks et il avait écrit une horreur du genre (j'écris n'importe quoi) "((~(n + 12) & 454) << 2) & 5) >> 2" et le compilateur avait simplifié en (un truc du genre) "n * 65". Donc en gros le mec voulait "optimiser" le "n * 65" en évitant la multiplication bah raté, non seulement le compilateur a compris son truc tordu, mais en plus il a quand même décidé de mettre une multiplication (mais les compilateurs sont en général balèze sur les opti mathématiques, ne prenez pas cet exemple en vous disant que le compilateur est trop intelligent en toutes circonstances, il peut être stupidement idiot par moments)
koala01 a écrit:
D'autres continuent même à le prétendre pour soutenir leur langage de prédilection parce qu'il ne leur autorise au final que ce paradigme.
Aha les pauvres Java-istes bloqués dans pOOP Land (ou OOPs Land selon les goûts), quoique ils ont quand même essayé de faire de la programmation fonctionnelle
koala01 a écrit:
D'ailleurs, si tu vas aux alentours du timestamp de 40:00, tu verras ses conclusions. Hé bien, figure toi que c'est ce que l'on rappelle à longueur d'année depuis ... je ne saurais même plus dire quand, tiens.
Vous dites ça mais après vous faites toujours de la POO partout. Même Google font ça, on se dit que chez Google ils doivent faire les meilleurs trucs possibles parce qu'ils valent $1500 milliards, bah non, des gars ont recodé la partie animation de Chromium et ils ont fait un truc 6 fois plus rapide https://youtu.be/yy8jQgmhbAU?t=2058 (vous y penserez quand votre page ramera car il y plein d'animations !)
"we did not change the algorithm [...] we're doing the same thing, only by reorganizing how the data is used, how the code is structured, we've gained 6 times better performance on this system"
Donc vous voyez que c'est pas forcément en isolant les trucs qu'on peut optimiser le mieux, là c'est par exemple en réfléchissant à comment les données circulent d'un bout à l'autre du programme, c'est ça que je veux dire quand je dit que favoriser la lisibilité en style OOP ça ferme des possibilités d'optimisation, car on ne voit plus clairement comment les données circulent d'une façon globale, chacun fait un truc isolé dans son coin.
c'est une bonne chose justement, ça fait un topique très informatif
En vrai, bof.
Ca serait intéressant si c'était une discussion sur les différentes approches possibles, les avantages et inconvénients de chaque méthode, les cas d'utilisation, une démarche pour designer et profiler, etc.
Mais là, c'est juste une discussion complètement décousue, qui part dans tous les sens, avec des arguments complètement bidons, une déconnection complète de la réalité, par une personne qui est complètement imbue d'elle même, sans aucune expérience, qui prend ses préférences personnelles pour des règles absolues, dont la seule expérience est d'avoir regardé des vidéos d'un gars qui n'est même pas capable de sortir un jeu en 10 ans, et qui est incapable de comprendre les problématiques au déjà de sa vision très limitée de la programmation.
Bref, il ne faut pas prendre cette discussion pour autre chose qu'une partie de détente, pour s'amuser et se défouler.
J'ai l'impression de regarder une vidéo d'Idriss Aberkane, avec une forme plutôt remplie (des arguments balancés, des liens dans tous les sens, des arguments fallacieux), mais un fond complètement vide (où il suffit de creuser un peu pour voir qu'en fait c'est du non-sens).
On en est vraiment au stade du "oui mais moi je préfère", si tu préfères des IDE rapide sans fonctionnalités, grand bien te fasse, ça existe. Mais ce n'est pas un argument, tu ne connais pas la réalité de l'industrie (qui a des raisons d'exister), on a pas tous dix ans pour développer un jeu amateur (ou un moteur de jeu amateur :D) en suroptimisant la moindre ligne de code qui n'en a pas besoin.
Cette discussion est stérile, tu ne comprendras pas tant que tu ne voudras pas comprendre, et tu ne voudras probablement pas comprendre avant d'avoir plus d'expérience.
À ce stade si on pouvait juste fermer les topics de JadeSalina qui traitent de Handmade Hero / Casey à vue, tout le monde y gagnerait, surtout JS.
Vous dites ça mais après vous faites toujours de la POO partout.
Même pas...
Il est vrai que, dans de nombreux cas, on fait ce que l'on pourrait appeler "de la OOP like", c'est à dire des classes qui ont des fonctions membres non virtuelles, mais qui ne recourent pas à l'héritage ni au polymorphisme par inclusion.
Et, si on le fait, c'est parce que cela facilite énormément les choses:
En rendant l'organisation du code "plus naturelle", car une fonction relative à la manipulation d'une donnée sera automatiquement placée avec ... les autres fonctions relatives à la manipulation de cette donnée (*)
En nous incitant à réfléchir à nos classes comme étant des fournisseurs de services au lieu d'y réfléchir comme un assemblage de données. Cela permet de mieux distinguer "ce qui doit être accessible au public" de ce qui est "détail d'implémentation"
parce qu'il n'y a aucune différence entre une fonction membre (non virtuelle) et une fonction libre prenant une instance de la donnée en paramètre (si ce n'est le fait de devoir utiliser cette instance de manière systématique dans la fonction membre
(*) Notes au passage que nous organiserons le code de la même manière avec l'approche impérative pure. Cela se fera peut-être seulement de manière "moins naturelle".
De plus, on ne le fait pas de manière systématique: on le fait quand cela a du sens. Quand, pour une raison ou une autre, cette approche "OOP like" n'a pas de sens, on passe bien volontiers à l'approche impérative pure, avec ses structures n'étant que des "empilements de données" et ses fonctions libres.
Et si l'approche impérative ne suffit pas, nous passerons volontiers à l'approche générique.
C'est ca, l'énorme intérêt de C++: C'est de ne pas nous limiter à une approche particulière lorsque ses inconvénients prennent le dessus sur ses avantages.
Et c'est notre manière habituelle de travailler: on prend le meilleur des trois mondes, et on assemble quelque chose qui tient la route et qui répond à nos besoin.
JadeSalina a écrit:
Même Google font ça, on se dit que chez Google ils doivent faire les meilleurs trucs possibles parce qu'ils valent $1500 milliards, bah non, des gars ont recodé la partie animation de Chromium et ils ont fait un truc 6 fois plus rapide https://youtu.be/yy8jQgmhbAU?t=2058 (vous y penserez quand votre page ramera car il y plein d'animations !)
"we did not change the algorithm [...] we're doing the same thing, only by reorganizing how the data is used, how the code is structured, we've gained 6 times better performance on this system"
Donc vous voyez que c'est pas forcément en isolant les trucs qu'on peut optimiser le mieux, là c'est par exemple en réfléchissant à comment les données circulent d'un bout à l'autre du programme, c'est ça que je veux dire quand je dit que favoriser la lisibilité en style OOP ça ferme des possibilités d'optimisation, car on ne voit plus clairement comment les données circulent d'une façon globale, chacun fait un truc isolé dans son coin.
Encore une fois, tu mélange tout et tu tire des généralités à partir de cas particuliers. Je te parle d'isoler le code, tu me parle réfléchir aux flux de données. Cherchez l'erreur.
Isoler le code, ca signifie que, si je décide de modifier l'organisation de mes données pour un truc particulier, je n'aurai que quelques fonctions bien spécifique à modifier pour que cela fonctionne, et que je ne devrai pas commencer à modifier le code de fonctions qui s'occupent de manipuler des éléments qui ne dépendent de ce truc particulier que de manière totalement indirecte.
Pour faire simple, je te parle de l'OCP.
Bien sur, l'OCP peut parfaitement être respecté avec l'approche impérative. Cela se fait simplement de manière "plus naturelle" avec une approche "OOP like".
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
d'un gars qui n'est même pas capable de sortir un jeu en 10 ans, et qui est incapable de comprendre les problématiques au déjà de sa vision très limitée de la programmation.
Bref, il ne faut pas prendre cette discussion pour autre chose qu'une partie de détente, pour s'amuser et se défouler.
On ne sait pas quel est son objectif, si il voulait sortir des jeux, il aurait pu directement utiliser Unreal et se concentrer sur le jeu mais apparemment ce n'est pas ce qu'il veut. C'est comme si vous critiquiez un professeur de maths de se contenter de donner des cours et de ne pas avoir fait avancé l'état de l'art dans le domaine, bah c'est juste pas son objectif.
Pour la vision limitée, je sais pas, moi je déteste ceux qui sont bloqués sur des vielles technos par flemme d'apprendre (et oui !), et je peux vous dire que j'en ai croisé des profs comme ça, qui enseignent des trucs périmés mais dont le cours est encore là car je cite "il faut bien payer ces profs". Pour Casey c'est vrai qu'il ne fait pas de C++ moderne, mais je pense que c'est par choix plus que par flemme de se mettre à jour, car même si il connait pas forcément les derniers trucs de C++, il connait au moins les grandes lignes.
Par exemple ici il voulait accéder à un champ d'une struct à la compilation, il ne savait pas comment faire en C++, il l'a fait en mode C en castant un pointeur nul, et sa conclusion c'est que ok il existe une syntaxe moderne, mais elle ne vaut même pas la peine de se "fatiguer" avec, car il le fait aussi bien avec sa macro : https://guide.handmadehero.org/code/day077/#4300
gbdivers a écrit:
Bref, il ne faut pas prendre cette discussion pour autre chose qu'une partie de détente, pour s'amuser et se défouler.
Ahah c'est comme ça que vous voyez mes topics ? Mais ils sont pas là pour s'amuser, c'est des discussions sérieuses au contraire !!
koala01 a écrit:
Et, si on le fait, c'est parce que cela facilite énormément les choses:
En rendant l'organisation du code "plus naturelle", car une fonction relative à la manipulation d'une donnée sera automatiquement placée avec ... les autres fonctions relatives à la manipulation de cette donnée (*)
Alors ça dépend de ce que vous mettez dans la classe... Si c'est pour mettre toutes les opérations possibles et imaginables sur l'objet en question, je trouve au contraire que c'est pas bien. Un de vos "dieux" a même des arguments par rapport à ça https://www.aristeia.com/Papers/CUJ_Feb_2000.pdf En gros il dit que :
Plus il y a de fonctions membres, moins il y a d'encapsulation, et donc qu'il ne faut mettre que le strict nécessaire en fonction membre
Mettre toutes les opérations dans la classe oblige l'utilisateur à inclure tout, alors qu'il a pas forcément besoin de tout (par exemple on peut vouloir une string, sans pour autant avoir tous les algorithmes possibles et imaginables manipulant une string). Il faut laisser le choix à l'utilisateur d'inclure tel ou tel header pour faire telle ou telle opération avec la classe.
Les soucis de "consistance" au niveau de la syntaxe d'appel (a.foo() vs foo(a)) ne sont pas une raison de tout mettre dans la classe, car il suffit que votre client rajoute une fonction (non membre, c'est tout ce qu'il peut faire) et bim il se retrouve avec l'inconsistance de syntaxe. D'ailleurs 2 autres de vos "guides spirituels" (dont le dieu des dieux olala :o) avaient proposé d'avoir une syntaxe uniforme, ça avait l'air cool (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4474.pdf)
koala01 a écrit:
C'est ca, l'énorme intérêt de C++: C'est de ne pas nous limiter à une approche particulière lorsque ses inconvénients prennent le dessus sur ses avantages.
Et c'est notre manière habituelle de travailler: on prend le meilleur des trois mondes, et on assemble quelque chose qui tient la route et qui répond à nos besoin.
Et je trouve aussi que c'est très bien d'avoir ce choix et merci de dire ça car entre nous, les vrais personnes "perdues" c'est celles bloqués en Python ou Java et qui sortent pas de leur bulle
Sinon vous dites que je dis des conneries, mais je ne fais que citer ce que d'autres experts ont dit, vous allez pas me dire qu'ils sont tous mauvais, j'en ai même cité qui sont de votre coté. Pour en revenir à ce que je disais, je suis tombée sur un vidéo où le mec dit exactement ce que j'ai dit (relisez mes messages précédents), et oui ce mec travaille réellement sur des gros projets et il a des décennies d'expérience, donc si vous devez pas m'écouter, écoutez le à lui :
"if it's not the fastest thing it could possibly be right out the gate, that's fine, so long as there is a path for you to get there. Too often, you're put in a position where you write something, and you've painted yourself into a corner, there's in fact no way for you to get to an optimized version of that"
"you might here somebody say, “well just measure this at the end and I'll fix it”. In real production, real life, real engineering, you can't just do that [...] half of the time you just need to throw everything away because you designed it wrong"
Donc oui bien sûr que c'est pas nécessaire d'avoir direct le truc le plus performant possible, et c'est même contre productif, mais c'est ça que je voulais dire quand je disais que certaines bonnes pratiques d'encapsulation ou autre peuvent parfois fermer des portes d'optimisation, il le dit lui même ! Et c'est ça le problème, c'est quand on ne peut plus atteindre un truc optimal car on a pensé le truc d'une manière théorique "à partir de diagrammes UML" ou ce genre de chose.
Ahah c'est comme ça que vous voyez mes topics ? Mais ils sont pas là pour s'amuser, c'est des discussions sérieuses au contraire !!
…
mais je ne fais que citer ce que d'autres experts ont dit
Quand je disais que tu es deconnecte de la realite…
A mon avis, personne ne te prend pour un interlocuteur serieux. Les gens te repondent uniquement pour que les autres qui lisent tes discussions aient des infos serieuses.
Ce qui est sur, c’est que personne ne te repond en esperant que tu comprennes ce qu’on t’explique.
Et tu as montre a plusieurs reprises que tu comprennais les choses comme elles t’arrangent. Citer des experts dans un domaine n’est pas suffisant, encore faut il comprendre ce qu’ils disent et ne pas avoir une lecture partialle.
JadeSalina a écrit:
Blablablab sur casey…
Pour resumer : si c’est casey qui le fait, c’est bien. Si c’est les autres, c’est des vieux cons pas a jour.
C’est probablement le plus dur avec toi : savoir quand tu trolles et que tu dis des conneries volontairement, ou savoir quand tu ne trolles pas et que tu dis des conneries au premier degre.
> ...vos "guides spirituels" ... Un de vos "dieux"...
On n'est pas comme toi, à suivre des "dieux", comme tu dis...
> mais c'est ça que je voulais dire
"Je retourne ma veste !"
> c'est des discussions sérieuses au contraire !!
Non, il n'y a aucun sérieux dans tes discussions, on y voit des jugements à l'emporte pièce, des phrases sorties de leur contexte, mais clairement aucun sérieux.
> ... Casey ... et sa conclusion c'est que ...
On s'en fout des conclusions de ce mec, il est temps de sortir de ton endoctrinement...
Si vous ne trouvez plus rien, cherchez autre chose.
Pour la vision limitée, je sais pas, moi je déteste ceux qui sont bloqués sur des vielles technos par flemme d'apprendre (et oui !),
Il faudra donc nous expliquer l'idolâtrie que tu portes à Casey, car, pour ce qui est de rester bloqué avec de veilles techno, il se pose quand même là
Peut être n'avais tu pas vu ces techniques durant ton cursus, mais cela ne veut pas dire qu'elle n'existaient pas, pour certaines, avant même ta naissance!
JadeSalina a écrit:
je peux vous dire que j'en ai croisé des profs comme ça, qui enseignent des trucs périmés mais dont le cours est encore là c
Et tu crois être la seule? Mais, Nom de dieu... Il ne se passe pas deux mois sans qu'on ne conseille à un étudiant de proposer à son prof de venir faire un tour par ici pour rafraichir ses connaissances, sans que
JadeSalina a écrit:
Pour Casey c'est vrai qu'il ne fait pas de C++ moderne, mais je pense que c'est par choix plus que par flemme de se mettre à jour, car même si il connait pas forcément les derniers trucs de C++, il connait au moins les grandes lignes.
Même cela,tu me permettra d'en douter...
Bon, après, il est vrai que je n'ai jamais eu la patience de suivre ses video jusqu'à la fin, tant elles arrivent à m'horripiler rapidement
JadeSalina a écrit:
Alors ça dépend de ce que vous mettez dans la classe... Si c'est pour mettre toutes les opérations possibles et imaginables sur l'objet en question,
Où as-tu vu, dans cette discussion ou ailleurs, que qui que ce soit plaidait pour mettre "tout et n'importe quoi" dans une seule classe?
Bien au contraire, on plaide en permanence pour le fait de garder l'interface des classes le plus simple possible.
Cela va même jusqu'au point où l'on déconseille très fortement d'utiliser des termes comme "manager" ou "gestionnaire" dans le nom des classes, justement pour éviter la tentation que ces termes induisent d'avoir une réflexion du genre "tel service, où vais-je le mettre ? Bah, c'est le role du manager (ou du gestionnaire) de gérer cela".
Et cela, par contre, tu peux trouver des dizaines de discussions dans lesquelles le conseil ou ses variantes apparaissent.
JadeSalina a écrit:
Un de vos "dieux"
En toute objectivité, il serait difficile de faire autre chose que de considérer Scott Meyers comme particulièrement ccmpétent. Et c'est ce que nous faisons effectivement
De là à le considérer "comme un dieu", il y a de la marge, car, même lui (ou B Strutroup ou bien d'autres types pour lesquels on a pourtant une haute estime ) ont dit des c...ries monumentales avec lesquelles nous étions en très large désaccord.
C'est d'ailleurs peut être ce qui nous sépare et qui fait que tu risques fort de rester à jamais une développeuse "tout juste moyenne", même si tu semble avoir correctement assimilé la théorie : ce n'est pas parce que quelqu'un pour qui on a une très grande estime dit quelque chose que l'on considère que c'est forcément parole d'évangile.
Ah, enfin un document "plus ou moins" contemporain de la prise de conscience du problème!!!
Mais dis moi, crois tu vraiment être la seule à l'avoir lu (et relu) en vingt ans? Crois tu que ce qu'il exprime dans ce document ne nous turlupinait pas déjà avant qu'il ne le mette noir sur blanc?
Crois tu même que nous n'avons pas fait évoluer ce point de vue au fil du temps?
JadeSalina a écrit:
En gros il dit que :
Plus il y a de fonctions membres, moins il y a d'encapsulation, et donc qu'il ne faut mettre que le strict nécessaire en fonction membre
Mettre toutes les opérations dans la classe oblige l'utilisateur à inclure tout, alors qu'il a pas forcément besoin de tout (par exemple on peut vouloir une string, sans pour autant avoir tous les algorithmes possibles et imaginables manipulant une string). Il faut laisser le choix à l'utilisateur d'inclure tel ou tel header pour faire telle ou telle opération avec la classe.
Les soucis de "consistance" au niveau de la syntaxe d'appel (a.foo() vs foo(a)) ne sont pas une raison de tout mettre dans la classe, car il suffit que votre client rajoute une fonction (non membre, c'est tout ce qu'il peut faire) et bim il se retrouve avec l'inconsistance de syntaxe. D'ailleurs 2 autres de vos "guides spirituels" (dont le dieu des dieux olala :o) avaient proposé d'avoir une syntaxe uniforme, ça avait l'air cool (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4474.pdf)
Donc, en gros, tu utilises un document qui a sans doute fait se poser des questions à certains d'entre nous lors de sa sortie (et dont je fais partie, vu que je l'ai lu à peu près à cette période), qui reprend exactement ce que l'on répète à longueur d'années depuis deux décennies, comme si tu venais à peine de découvrir ces vérités?
Et le pire de tout, c'est que tu es persuadée que nous, pauvres cons incompétents que nous sommes, nous faisons exactement tout le contraire de ce qui est expliqué dans ce document.
Mais qui vit dans sa bulle ici????
- Edité par koala01 14 juillet 2022 à 7:25:11
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
@-L0Lock- a écrit: Perso, je considère que c'est une bonne chose justement, ça fait un topique très informatif avec des boutades en prime. Je suis aveugle et je ne vois pas les vidéos. Est-ce que du moins Casey est beau bonhomme s'il n'a pas d'autres qualités?
Le Tout est souvent plus grand que la somme de ses parties.
Pour faire simple: les limites arbitraires (comprends: qui ne se base que sur des calculs imprécis et des évaluations "à la grosse louche" des besoins réels) ne sont jamais une bonne chose en pratique.
Re les ami.(e).s, j'étais tranquillement en train de regarder une interview de John Carmack quand tout a coup il a dit un truc qui m'a fait penser à ce que vous écrivez là, en gros il dit au contraire que c'est très bien d'imposer des limites et d'utiliser juste des tableaux statiques, déjà car c'est plus performant et plus safe (pas d'allocations qui peuvent prendre du temps/foirer en plein milieu), mais aussi car si on a écrit tout le code autour en supposant qu'on avait pas beaucoup d'éléments, il vaut mieux qu'on atteigne la limite et que ça nous "pète à la guele" plutôt que ça laisse tranquillement le nombre d'élément monter, car tout le code autour a peut être besoin d'être repensé justement pour gérer plus d'éléments. https://www.youtube.com/watch?v=I845O57ZSy4&t=3992s
Et John Carmack c'est quand même quelqu'un, vous ne pouvez pas le nier
(j'ai pas fini de regarder la vidéo, peut être que je reviendrai plus tard pour dire d'autres trucs très intéressants)
Il ne mentionne ni l'allocation dynamique, ni les échecs
Quant au reste, c'est une déformation de ses propos:
Il trouve bien d'imposer une limite pour détecter les changements non prévus dans l'environnement. Que se soit suite à un changement de code ou de contexte. Mais il ne faut pas se le cacher, soit le comportement est voulu et la limite devra être repoussé, soit cela se rapproche plus d'un bug.
Il trouve bien d'utiliser un tableau statique parce que le code autour impose des tailles limites... Merci Sherlock
Comme d'habitude, il y a beaucoup d'extrapolation et de déformation de ta part. Je pense qu'on pourra se passer de tes autres commentaires sur la vidéo
Qu'est-ce qu'il a ce code ? J'ai pas tout regardé mais on dirait du code à la Casey. D'ailleurs il avait tweeté un truc très pertinent, qui montre que l'approche C++ n'est pas la bonne pour la gestion mémoire, j'allais pas en faire un topic donc je le met ici : https://twitter.com/cmuratori/status/1553951412878381057
C'est écrit, entre autre par John Carmack. C'est du C, et si tu regardes bien, tu y trouveras ce que tu t'efforce de décrier ici: Des allocation dynamiques.
D'ailleurs il avait tweeté un truc très pertinent, qui montre que l'approche C++ n'est pas la bonne pour la gestion mémoire, j'allais pas en faire un topic donc je le met ici : https://twitter.com/cmuratori/status/1553951412878381057
Rien de pertinent là dedans, c'est du Casey, comme d'hab' quoi... (et puis on s'en fout de ton dieu)
Si vous ne trouvez plus rien, cherchez autre chose.
Alors même si encore une fois, il est vrai qu'il vaut mieux minimiser les allocations, je voulais parler de John Carmack :
Il vient d'une autre époque. Une époque ou les pross étaient peu puissants, et ou la mémoire était rare.
Donc il cherchait toutes les optimisations possibles. D'ailleurs il y a son remarquable algo sur le calcul de l'inverse de racine carrée (utilisé pour les normales et donc les lumières) sur des pross qui géraient encore mal les nombres à virgule flottante.
Alors bien sur oui, si tu peux éviter de faire trop d'allocations c'est mieux. Cependant, on n'est plus du tout dans le même contexte qu'avant : on a de la mémoire à gogo et des pross beaucoup plus optimisés. Beaucoup de ses recommandations sont caduques.
Oserais-je te dire que ton idole Casey a 30 ans de retard ?
C'est vrai qu'il dit des trucs bizarres des fois, il dit aussi que le garbage collector c'est bien https://youtu.be/I845O57ZSy4?t=1323 il faut pas écouter tout ce qu'il dit.
@Fvirtman Oui c'est vrai que c'est moins nécessaire aujourd'hui de faire attention aux ressources, c'est pour ça qu'il vaut mieux justement faire comme Casey, c'est à dire tout allouer d'une façon linéaire à partir d'un bloc mémoire, le seul défaut de cette approche c'est qu'on ne peut pas libérer individuellement des morceaux de mémoire, puisque on alloue comme sur une pile, donc si on veut allouer un objet A puis B, et libérer le A, on ne peut pas vraiment réutiliser sa mémoire (sauf si on alloue toujours des objets de même taille, on peut tracker les emplacements libres (comme une memory pool)).
Donc au final c'est vous qui n'exploitez pas le matériel d'aujourd'hui en essayant d'allouer et désallouer chaque petit truc indépendamment pour libérer la mémoire "le plus tôt possible", alors que comme vous dites on s'en fou. En fait avec l'approche de Casey on gagne en performance (pas d'allocations à faire à tout va), en fiabilité et le code est plus simple (mais ok comme il dit dans le tweet, avec tous vos "bagages encombrants" de C++, je reconnais qu'on atteint une certaine fiabilité aussi (mais attention quand même à ne pas faire de copies malencontreuses en oubliant de move par exemple)). Par contre en terme de ce qui s'exécute sur la machine, c'est beaucoup plus lourd par rapport à l'approche de Casey, qui est bien plus performante en temps.
Et autre exemple de vous qui n'utilisez pas le matériel, vous faites vos interfaces avec Qt qui va essayer de faire le moins d'opérations possibles, au prix d'une programmation méga chiante et lourde, alors qu'on peut faire la même chose avec Dear Imgui avec un code très simple et clair et pas avec des relations entre 36000 objets qui communiquent à tout va. L'inconvénient de Dear Imgui c'est qu'on va généralement refaire certains calculs qui auraient pu être évités, mais vous savez quoi ? Si justement on ne peut pas éviter ces calculs car on a une interface hautement dynamique, Dear Imgui repasse devant en terme de performance ! Et oui car en mode immédiat on "fait ce qu'il y a à faire", ni plus ni moins, alors qu'avec Qt il y a toute une architecture derrière pour minimiser les calculs, mais quand il FAUT quand même faire ces calculs, on doit se taper en plus toute la synchronisation etc. Le genre d'interface très adapté à ça c'est les profilers, qui serait juste super lents avec une interface en Qt : https://twitter.com/Donzanoid/status/1536445311224270850
Et sans même parler de tout ce que je dit, si on regarde juste les logiciels actuels etc, pourquoi ils sont aussi lents ? Vous avez une explication ? J'en ai déjà parlé, mais même des vieilles versions de Visual Studio sont beaucoup plus rapides sur des Pentium que VS2022 sur un i9 !! POURQUOI ??
OuI Mé yA BeAUcOuP PlUS dE fOnCtioNalitéS
Bah au pire on s'en fou ? Si c'est pour ne pas les utiliser et que en plus ça rend tout super lent au point de ne pas pouvoir faire ce qu'on faisait déjà avant c'est débile non ? Encore un tweet posté pile le jour où je parle de ça https://twitter.com/MichaMettke/status/1556659304987508736 (lisez les réponses aussi)
Lynix, je sais que vous utilisez beaucoup de C++ moderne dans Nazara et donc je vous souhaite qu'il puisse quand même bien tourner sur le web, et que la page ne soit pas trop grosse à télécharger etc, malheureusement le C++ moderne n'encourage pas à faire du code "léger" à exécuter donc c'est un peu dommage. Ca ne vous dérange pas d'avoir un truc plus lourd que ce qu'il devrait ? Que l'appareil qui va faire tourner la page se mette à chauffer et allumer les ventilateurs alors qu'il aurait pu éviter ? Si ça peut servir : https://floooh.github.io/2016/08/27/asmjs-diet.html (j'ai l'impression de toujours citer les mêmes personnes mais que voulez vous, emscripten eux-même citent cet article)
Et autre exemple de vous qui n'utilisez pas le matériel, vous faites vos interfaces avec Qt qui va essayer de faire le moins d'opérations possibles, au prix d'une programmation méga chiante et lourde, alors qu'on peut faire la même chose avec Dear Imgui avec un code très simple et clair et pas avec des relations entre 36000 objets qui communiquent à tout va. L'inconvénient de Dear Imgui c'est qu'on va généralement refaire certains calculs qui auraient pu être évités, mais vous savez quoi ? Si justement on ne peut pas éviter ces calculs car on a une interface hautement dynamique, Dear Imgui repasse devant en terme de performance !
A ceci près que dear imgui n'est pas du tout prévu pour faire la même chose que Qt. Je cite:
Dear ImGui is designed to enable fast iterations and to empower programmers to create content creation tools and visualization / debug tools (as opposed to UI for the average end-user). It favors simplicity and productivity toward this goal, and lacks certain features normally found in more high-level libraries.
Dear ImGui is particularly suited to integration in games engine (for tooling), real-time 3D applications, fullscreen applications, embedded applications, or any applications on consoles platforms where operating system features are non-standard.
[ Dear ImGui est conçu pour permettre des itérations rapides et permettre aux programmeurs de créer des outils de création de contenu et des outils de visualisation/débogage (par opposition à l'interface utilisateur pour l'utilisateur final moyen). Il privilégie la simplicité et la productivité vers cet objectif, et manque de certaines fonctionnalités que l'on trouve normalement dans les bibliothèques de plus haut niveau.]
[Dear ImGui est particulièrement adapté à l'intégration dans le moteur de jeux (pour l'outillage), les applications 3D temps réel, les applications plein écran, les applications embarquées ou toute application sur les plates-formes de consoles où les fonctionnalités du système d'exploitation ne sont pas standard.]
Le développeur le dit lui-même: Dear Imgui est destinée au développeur, pour lui permettre d'accéder aux données qui l'intéressent à un instant précis, mais qu'il n'aura aucun remords à remplacer par d'autres dans cinq minutes, parce qu'il sera passé à autre chose.
Cela n'a rien à voir avec Qt, qui est clairement orientée vers le fait de fournir quelque chose qui soit spécifiquement destiné à l'utilisateur final, avec tout ce que cela peut impliquer.
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
Discord NaN. Mon site.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Moderateur forum || FAQ 3D || discord 3D francophone || OC Tweak script
Discord NaN. Mon site.
Mes articles | Nazara Engine | Discord NaN | Ma chaîne Twitch (programmation)
Discord NaN. Mon site.
Si vous ne trouvez plus rien, cherchez autre chose.
Le Tout est souvent plus grand que la somme de ses parties.
Discord NaN. Mon site.
Discord NaN. Mon site.
Si vous ne trouvez plus rien, cherchez autre chose.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html