@michelbillaud Merci pour votre réponse, effectivement std::optional permet de faire ça, mais il reste le fait que Task n'est pas complètement initialisé à la construction et qu'il faut manuellement appeler init, moi ça me va mais ça s'éloigne un peu du concept d'avoir toujours une variable bien initialisée.
J'ai un autre problème par rapport à la gestion des textures. J'ai une classe "Texture" qui représente une ressource du GPU. Il faut donc lui ajouter cette sémantique. J'ai choisi de ne pas autoriser la copie, mais on aurait pu imaginer stocker un shared_ptr interne pour pouvoir avoir plusieurs propriétaires et pouvoir la détruire quand plus personne ne l'utilise. Par contre il est possible de la move. Le problème que j'ai est que quand on move-construct une texture, la "moved-from" texture sera détruite automatiquement par le destructeur. Mais justement on ne veux pas qu'elle détruise la texture du GPU puisqu'on vient de lui voler ! La solution que j'ai trouvé est donc, dans le move constructor, de mettre l'ID de l'autre texture à 0, ce qui fait que quand elle se fera détruire, elle détruira une texture vide et non celle qu'on vient de voler. Est-ce que c'est moi qui comprends rien, où est-ce que ça signifie que le destructeur de la moved-from texture sera systématiquement appelé, même si il ne faut justement pas détruire la ressource qu'on vient de prendre ? C'est le comportement attendu où c'est moi qui utilise mal les move semantics ? J'ai l'impression de "tricher" en lui passant un ID de 0, au lieu de simplement ne pas appeler son destructeur, ou quelque chose comme ça (ce qu'on ne peut pas faire à ma connaissance). Peut être que Sir pourrait m'éclairer vu qu'il fait un moteur de jeu. (après j'ai une autre question sur pourquoi avoir plusieurs propriétaires de la texture mais je la poserai après)
mais ça s'éloigne un peu du concept d'avoir toujours une variable bien initialisée.
Non, c'est juste que tu n'as pas compris ce que veut dire "bien initialisée". Tu confonds "initialisation" et "allocation des ressources", parce que tu n'as pas compris ce qu'est la qualité logicielle, ce qu'est un invariant de classe et ce qu'on attend d'un constructeur/destructeur.
std:vector<int> v; // initialisation de la classe
... bien plus tard...
v.resize(N); // allocation de la mémoire
Le fait de dire qu'on préfère en C++ créer les variables au moment où on en a besoin, de préférer l'initialiser directement avec les bonnes données et de préférer utiliser "const", cela ne veut pas dire que c'est la seule méthode valide de faire. Et on t'a déjà cité pleins d'exemple, comme les memory pool ou la lazy evaluation.
Mais les sources que tu regardes sont, encore une fois, obsolètes. Il (HH) travaille sur des vieux codes, avec peu de lignes de code, tout seul. Les contraintes de qualité sont très faibles et c'est pour ca qu'il n'a pas de tests (pour ce que j'ai vu), qu'il ne respecte pas les normes de qualité et qu'il peut se permettre de faire du code moisi qui date d'il y a 20 ans. Parce que moins le code est critique, moins il sera un problème de faire du code moisi.
Et c'est pour ca que tu ne pourras pas comprendre le pourquoi du C++ moderne en pensant le code comme il y a 20 ans.
Tu as passé des heures et des heures a regarder ses vidéos. Maintenant, passe des heures et des heures a regarder les videos de CppCon. Tu as le crane tellement bourré de ce code moisi qu'on ne pourra jamais t'expliquer avec quelques messages sur le forum toutes les erreurs que tu as appris.
Bon, ne pas initialiser complètement Task, c'était une demande expresse du client, alors il faudrait savoir ce qu'on veut, à un moment....
> il est possible de le move
Ça serait mieux de faire une phrase en français, qui dirait pourquoi on aurait besoin de ça.
Parce qu'on peut faire plein de choses. Move et pas move.
- Edité par michelbillaud il y a 12 minutes
Ah peut être qu'il vaut mieux désactiver la copie et le move et simplement passer des références à droite à gauche ? Le problème est que du coup l'endroit où la texture est créée sera sa dernière demeure puisqu'on ne pourrait pas la déplacer. Et la texture n'est sans doute pas déclarée dans un membre ou autre, elle serait plutôt créée par un système d'assets ou quelque chose comme ça, et donc pouvoir la déplacer me parait indispensable...
Hum... Quand je lis buffer j'entends vector<machin>. Alors si le backbuffer est bien un vecteur, il suffit de lui foutre la paix dans le ctr et il sera vide, quand à la destruction d'un vecteur vide, c'est peanuts. Si par contre c'est un objet plus complexe, OK cela a une tête d'optional, mais franchement... ça me laisse un arrière goût de design-smell.
Il y a un truc que je n'avais pas bien compris en sortant de l'école et qui est mieux rentré maintenant: invariants, invariants et invariants! Un ctr positionne les invariants d'un objet, tous les services publics continuent à assurer les invariants de l'objet jusqu'à la destruction, et si jamais on a des zones d'invariants différents, on tache de faire en sorte qu'elles s’emboîtent. Et tout est tellement plus simple après. Moderne? Hum... je soupçonne que c'est encore plus vieux que le C.
Si ta texture ou ton renderer dépend de données dans un certain état, alors établis bien ses invariants. Peut-etre il sera nécessaire d'introduire une couche intermédiaire, les jeux ce n'est pas mon métier.
mais ça s'éloigne un peu du concept d'avoir toujours une variable bien initialisée.
tu n'as pas compris ce qu'est la qualité logicielle, ce qu'est un invariant de classe
Si ça fait partie partie des trucs que j'ai vu à l'école, mais ok pour l'exemple du vector. Et non il n'y a pas de tests dans HH car c'est du code temporaire, qui est une autre notion que j'ai vu chez Casey et J. Blow, c'est d'écrire du code simple et réorganiser au fur et à mesure qu'on ajoute des features, ce qui fait qu'on ne peut pas vraiment tester le code tant que l'API n'est pas "mature" (peut-être que telle fonctionnalité va demander une restructuration de tel ou tel truc, et donc changer son interface etc).
gbdivers a écrit:
bacelar a écrit:
>Mais justement on ne veux pas qu'elle détruise la texture du GPU puisqu'on vient de lui voler ! ...
"Ta" solution, bin, c'est la manière "idiomatique" de faire ne C++ moderne, on parle de vampirisation de l'objet déplacé par le constructeur.
Et sinon, la "idiomatique de faire ne C++ moderne", c'est surtout de ne pas écrire les move operations a la main (regle des 0).
Oui on est d'accord, quand je vois des trucs comme ça https://github.com/angeluriot/Chess_AI/blob/master/sources/BitBoard.cpp j'ai envie de me crever les yeux, mais là il y a bien une sémantique particulière à la texture qui est d'être une ressource GPU qu'il faut créer et détruire non ?
Et l'autre question c'est pourquoi vouloir que plusieurs propriétaires possèdent la texture (peut être à poser à Sir, qui fait ce genre de choses) ? Mais pourquoi ne pas juste déléguer ça à un système d'assets par exemple ? Car si n'importe qui peut posséder les textures, comment faire pour tracker la mémoire totale utilisée, ou ce genre de choses ? Alors que si par exemple seul le système d'asset est responsable et que les autres manipulent juste des références, on peut gérer quelles sont les textures utilisées, libérer celles qui ne sont plus "visibles" ou des trucs comme ça.
Et non il n'y a pas de tests dans HH car c'est du code temporaire, qui est une autre notion que j'ai vu chez Casey et J. Blow, c'est d'écrire du code simple et réorganiser au fur et à mesure qu'on ajoute des features, ce qui fait qu'on ne peut pas vraiment tester le code tant que l'API n'est pas "mature" (peut-être que telle fonctionnalité va demander une restructuration de tel ou tel truc, et donc changer son interface etc).
Donc aucune validation fonctionnelle du logicielle. Inacceptable dans les standards de qualité des entreprises.
Et quand tu as écrit des tests pour valider ton logiciel, tu veux éviter de modifier le code qui est validé, parce que cela implique de devoir valider le code. Et donc tu respectes les principes de qualité (SOLID), tu fais des abstractions, tu fais du code réutilisable, etc.
Tu as l'impression que les logiciels sont plus mauvais de nos jours, mais c'est une fausse impression. Le taux d'erreur par ligne de code est bien meilleur de nos jours. Mais il y a aussi beaucoup beaucoup plus de lignes de code.
HH peut se permettre de faire du code moisi (et donc avoir un taux d'erreur par ligne de code plus élevé) justement parce qu'il bosse sur des petits projets. (Oui, tu as du mal à comprendre ce point, mais un projet fait en quelques mois - en équivalent temps plein - par une personne seule, c'est un petit projet).
Bref, tout découle (comme l'a dit Helba) que HH fait du indé/petit projets et que le C++ "moderne" (et tous les langages et approches "modernes") sont pensé pour répondre aux contraintes des logiciels modernes.
Mais tu regardes du code de débutants là, qui contient pleins d'erreurs et de mauvaises pratiques.
JadeSalina a écrit:
mais là il y a bien une sémantique particulière à la texture qui est d'être une ressource GPU qu'il faut créer et détruire non ?
Il n'y a aucune encapsulation de la texture dans le code que tu donne. Donc je sais pas trop de quelle sémantique tu parles. (Mais du coup, je dirais qu'il n'y a justement aucune sémantique).
JadeSalina a écrit:
Et l'autre question c'est pourquoi vouloir que plusieurs propriétaires possèdent la texture (peut être à poser à Sir, qui fait ce genre de choses) ? Mais pourquoi ne pas juste déléguer ça à un système d'assets par exemple ? Car si n'importe qui peut posséder les textures, comment faire pour tracker la mémoire totale utilisée, ou ce genre de choses ? Alors que si par exemple seul le système d'asset est responsable et que les autres manipulent juste des références, on peut gérer quelles sont les textures utilisées, libérer celles qui ne sont plus "visibles" ou des trucs comme ça.
Pourquoi pas ?
C'est juste une question de design et de choix. On va préférer un gestionnaire de ressources en général, mais sur un petit projet, pourquoi pas.
Mais ce n'est plus une question "C++". C'est une question general de design de la gestion des ressources. Et il y a des dizaines d'approches possibles.
Après moi j'ai pas d'expérience pour savoir ce qui marche ou pas en pratique. J'ai vu des CppCon de Kate Gregory, Jason Turner, Herb Sutter etc et je me disait "bah oui ils ont raison c'est comme ça qu'il faut faire" mais c'est en voyant des Casey ou J. Blow qui ont plus de 30 ans d'expérience que je me suis posée des questions. Je vais pas pouvoir aller beaucoup plus loin dans le débat puisque j'ai pas l'expérience requise mais l'idée originale du topic était de me tourner vers des professionnels de la programmation et du C++ pour savoir si les techniques de Casey et cie étaient bonnes. Je sais que vous avez pas le temps pour ça mais je laisse quand même quelques extraits de HH qui peuvent être intéressants (je n'ai pas l'expérience pour juger ce qu'il dit, mais je sais juste qu'il a 30 ans d'exp)
"C++ is designed to make lousy programmers make less mistakes" (https://guide.handmadehero.org/code/day415/#5211)
"C++ Commitee is some of the worst designers that has ever come together to make a language" (https://guide.handmadehero.org/code/day182/#4295)
"C++ dynamic dispatch is dumb, they don't know how to program a computer" (https://guide.handmadehero.org/code/day277/#3653)
"The C++ commitee always fails to grasp how a programming language should work" (https://guide.handmadehero.org/code/day384/#2122)
"C++ is a way lost cause, everytime the C++ commitee tries to do something, they designed the worst possible version of that thing" (https://guide.handmadehero.org/code/day414/#6781)
"Don't impose an artificial structure on the code, OOP is crap" (https://guide.handmadehero.org/code/day437/#6838)
"The OOP C++ codebases are ridiculous, they are wrong" (https://guide.handmadehero.org/code/day467/#7846)
"RAII is wrong, just use memory arenas. I would not use any unique_ptr/shared_ptr nonsense. RAII is only for toy programming, when people use that, they don't know what they're doing" (https://guide.handmadehero.org/code/day468/#6313)
"C++ features are crappy, templates and virtual functions are wrong" (https://guide.handmadehero.org/code/day443/#6465)
"C++ is not maintained by people that know what they're doing" (https://guide.handmadehero.org/code/day206/#4329)
"Getters/setters are bad, because the people who made C++ don't know what they're doing. Bjarne stroustrup is particularly bad" (https://guide.handmadehero.org/code/day212/#4080)
Casey connaît la COO, mais la trouve limitée (https://guide.handmadehero.org/code/day449/#7031)
"The STL is garbage and should never be used for any purpose at any time" (https://guide.handmadehero.org/code/day471/#8353)
"C++ is a giant steaming pile of dog turd" (https://guide.handmadehero.org/code/day422/#6614)
"C++ commitee always include features that don't work. They don't know how to program" (https://guide.handmadehero.org/code/day227/#4373)
"C++, they pick the name right because it's a post-incrementation, we get back C in the expression. They are not consistent with their own joke" (https://guide.handmadehero.org/code/day246/#4266)
- Edité par JadeSalina 28 septembre 2021 à 22:12:24
mais l'idée originale du topic était de me tourner vers des professionnels de la programmation et du C++ pour savoir si les techniques de Casey et cie étaient bonnes. Je sais que vous avez pas le temps pour ça mais je laisse quand même quelques extraits de HH qui peuvent être intéressants (je n'ai pas l'expérience pour juger ce qu'il dit, mais je sais juste qu'il a 30 ans d'exp)
Ben, tu as ta réponse : non.
Et il n'a pas 30 ans d'expérience en C++. Son code est du C, il ne connaît pas la POO, ni le C++, ni comment on conçoit des logiciels de nos jours.
(Je n'ai pas regardé tous tes liens, mais les ~~3~~ 7 que j'ai ouvert, c'est bof. Ca me donne pas envie de tout regarder. EDIT : je confirme, aucun intérêt de tout regarder, c'est complètement moisi)
EDIT : en fait, tous ces "tous les devs C++ sont nuls, seul moi comprend les choses", Casey est juste un gros con arrogant, non ?
EDIT : en fait, tous ces "tous les devs C++ sont nuls, seul moi comprend les choses", Casey est juste un gros con arrogant, non ?
quand le mec sur son blog dit ça : "The problem with the internet is that everyone thinks they’re an expert. That would be fine, if everyone actually was an expert, but the truth is that only I am an expert, so it’s just frustrating." J'ai envie de dire oui ^^'
J'ai pas mal lu son blog , et il aime bien donner son avis sur tout... (Il avait un article qui parlait de matériel , forcément j'ai bien souri )
Il n'est pas impossible que ça soit de l'humour, genre auto-dérision, pour une serie de "rantings" sur quelques problèmes avec son langage favori et ceux qui l'utilisent.
Il y a d'autres exemples, Linux Hater's Handbook..
- Edité par michelbillaud 29 septembre 2021 à 8:45:06
Il n'est pas impossible que ça soit de l'humour, genre auto-dérision, pour une serie de "rantings" sur quelques problèmes avec son langage favori et ceux qui l'utilisent.
Il y a d'autres exemples, Linux Hater's Handbook..
Si seulement...
Mais j'en doute très fort, ces citations font partie de réponses qu'il donne à des questions posées "en directe" et qu'il en arrive toujours non seulement à justifier ces réponses (par un raisonnement qui s'arrête trop tôt) et qu'il en vient toujours à un moment ou à un autre à dire "et je ne discuterai pas de cela", pour bien fermer la porte à toute véléhité de réaction
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
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.