rewind a écrit 3429 commentaires

C'est justement ce que je conteste. La notion de type est une notion technique induite par la manière dont l'ordinateur stocke les données et par l'utilisation que tu peux en faire.

Malheureusement, on ne code pas encore sur des pizzas mais sur des ordinateurs, donc savoir ce qu'est capable de faire un ordinateur pour lui donner les bonnes instructions, c'est ça la programmation.

Pour un débutant, il pourrait n'exister que deux types de données : les nombres et les chaines de caractères.

Je vais te donner un problème simple : tu as un tonneau de x litres et des bouteilles de y litres, combien de bouteilles te faut-il pour vider le tonneau ? Et bien si tu ne sais pas si ton nombre est un entier ou un flottant, tu pourrais très bien ne pas savoir résoudre ce problème.

Il ne faut pas prendre le débutant pour un débile.

Ce n'est pas mon cas, moi je veux lui apprendre les types et la manière de les choisir pour résoudre un problème, pas lui faire croire que tout est pareil et que l'ordinateur va bien se débrouiller pour comprendre ce qu'il a voulu dire. Il y a un exercice classique qu'on donne en première année, c'est la calculatrice : il faut rentrer deux nombres (donc deux variables, mettons a et b) et un opérateur (qu'on stocke dans un caractère qu'on appelle op). Et bien c'est généralement là qu'on voit ceux qui ont compris et ceux qui restent à «l'ordinateur doit comprendre ce que je lui dit». Ces derniers écrivent : res = a op b qui n'a absolument aucun sens. Et qui est du même acabit que 4 + "4" à mon avis. Et souvent, même quand on leur a expliqué, ils ont du mal à comprendre pourquoi ça ne marche pas.

C'est pareil que pour la différence entre un int et un float ; la différence n'existe qu'à cause d'une contrainte technique.

Absolument pas. Voir mon problème simple ci-dessus avec les bouteilles. C'est fondamentalement différent, même sans aller jusqu'à parler des limites des entiers ou des floats.

Mais je vois ça comme un défaut inhérent à la formalisation d'un programme, ça n'est pas intuitif, et ça n'est pas important pour comprendre la logique d'un programme.

J'insiste, un programme, ce n'est pas qu'une «logique», c'est également un choix adéquat de types et de structures de données et ce n'est pas une nouveauté !

À mon avis, l'intérêt du typage fort ne saute aux yeux qu'après des années à avoir expérimenté les bugs dus aux ambiguités du typage faible.

Ce ne sont pas des ambiguïtés, c'est une manière erronée d'apprendre les choses. Ça va beaucoup mieux dans le sens inverse : quand on a compris les types, on sait mieux utiliser les langages faiblement typés.

"C'est compliqué et ça vous gêne maintenant, mais vous verrez plus tard que c'est important" est un argument très faible ; c'est un argument d'autorité, souvent d'ailleurs employé pour justifier une pédagogie archaïque

Premièrement, ce n'est pas compliqué, c'est même plutôt naturel. Deuxièmement, ça a des applications très concrètes et très rapidement, aucun argument d'autorité derrière. On peut montrer que c'est utile (et j'ai donné deux exemples qui montrent que ça a du sens comparé à une approche trop empirique !) et que ça ne gêne personne, au contraire, ça permet d'avoir une meilleure maîtrise de ce qu'on fait.

Plus il y a de choses intuitives et plus l'élève va pouvoir se concentrer sur les aspects logiques du code. Les aspects techniques, il les apprendra plus tard.

La notion de type est très très loin d'être une notion technique. De nos jours, on a pris conscience que les données sont tout aussi importante que le code qui les manipule. Bien choisir comment représenter ses données, ça fait partie de l'apprentissage de la programmation. Pour moi, apprendre uniquement des structures de contrôles et faire l'impasse sur les types, c'est faire la moitié du boulot. Dans mon univ, on donne un quantité impressionnante d'exercice en première année dans lesquels le choix du bon type est importante pour la résolution du problème. Et je ne parle même pas de structure là, juste entier/flottant/booléen/caractère.

Je pense que si la différence entre les deux n'est pas visible, c'est d'une part (comme dit plus haut) parce qu'il y a les appels SDL qui prennent beaucoup de temps, et d'autre part, parce que tes composants sont petits et peu nombreux, ce qui fait que même avec le layout "array of struct", tu as une bonne localité des données. Il faudrait faire le même test avec des données plus grosses et je pense qu'on verrait la différence. J'essaierai de bricoler un truc si je trouve du temps.

Dernier point, ton benchmark étant simple, il omet une des difficultés (à mon goût) des E/S : comment stocker de manière efficaces des composants pour N entités sachant que les entités n'ont pas toutes les mêmes composants.

Il doit mal expliquer mais en fait, c'est exactement ce qu'il fait : comparer comment stocker les entités. Avec deux variantes : "struct of array" et "array of struct".

(dans mon cas j'ai choisis après divers test : une entité représente un index, et les composants sont stockés dans des std::vector. Ça permet d'améliorer l'utilisation du cache pour l'opération la plus couteuse : la maj des systèmes)

Dans son cas, ce sont aussi des vector. Et toutes les entités ont potentiellement tous les composants (d'après ce que j'en ai compris).

Il compare le layout "struct of array" vs "array of struct" pour voir quelle est le meilleur en terme de performance.

Le conteneur peut être une hashmap ou un arbre.

Localité des données et arbre (ou hashmap) ne font pas bon ménage (vu que c'est bourré d'indirections). Ou alors, il y a un truc que je n'ai pas compris.

Moi, avec mes PDF (beamer), je les gonfle car il ne peuvent pas faire copier coller ;-)

C'est une de mes features préférées de beamer face à PowerPoint !

En fait, tu prends les chiffres qui t'arrangent pour servir un propos qui t'arrange. Mais le fait est là : il est possible de se faire beaucoup d'argent en dehors des États-Unis (ce qui invalide ton propos). Je peux prendre un exemple européen si tu veux. Volkswagen par exemple ne vend pas énormément de voiture aux États-Unis, n'est pas un monopole, et pourtant, pareil, dans le top 10 mondial pour le CA. Mais c'est sans doute pas pareil non plus.

Sinon, les réserves de changes de la Chine, c'est en roubles, c'est ça?

Depuis longtemps, la Chine essaie de diversifier ses réserves pour ne plus dépendre du dollar.

Tu parles de PIB là, donc uniquement d'économie. En quoi tout ce que tu dis a un quelconque rapport ? La zone européenne est intégré économiquement, donc ça a un sens de la considérer comme une unité, même si ce n'est pas un pays.

Connaîs-tu les entreprises Sinopec, China National Petroleum Corporation ou State Grid Corporation ? Pourtant, elles font partie des 10 plus grandes entreprises au monde (en terme de CA) et elles ne sont absolument pas implantés aux US. Ce sont des entreprises chinoises. Le monde n'est plus centré autour des US. Il se passe plein de chose ailleurs qui font que les US sont en train de perdre leur leaderchip. Comme par exemple l'accord entre la Chine et la Russie pour ne plus utiliser le dollar pour leurs échanges, l'accord entre les BRICS pour avoir un équivalent de la Banque Mondiale et du FMI mais sans utiliser le dollar, etc. Ton américanisme béat n'y changera rien, le monde évolue.

L'UE est une région fortement intégré économiquement, qui partage (pour une bonne part) la même monnaie et dont les principales décisions économiques (puisqu'on parle de PIB) sont coordonnées à la Commission. Certes, ce n'est pas un pays, mais il faut être sacrément de mauvaise foi pour continuer à comparer des trucs pas comparables et refuser de comparer ce qu'on peut comparer parce que sinon ça risque de fâcher l'Oncle Sam.

C'est une blague… Tu prends une entreprise américaine, normal qu'elle fasse un gros chiffre dans son pays. Prend une grosse entreprise française, tu vas voir, elle fait aussi au moins 50% de son chiffre en France. Et tu peux faire pareil avec chaque leader industriel de chaque pays. Ton exemple n'a pas de sens.

C'est quoi l'intérêt de copier/coller un truc qu'on peut aller lire en cliquant sur le lien ?

Tu as un exemple de projet.xml et les feuilles XSLT sur un dépôt quelque part ?

Exactement, les cas particuliers sont gérés par du code particulier. Et le cas simple de 99% des gens, et bien une simple déclaration suffit. Et c'est tout ce que demande devnewton.

Aucune option particulière, mais j'autorise les fichiers core (avec ulimit -c unlimited), c'est peut-être ça ton souci. Ensuite, je lance gdb avec le nom de l'exécutable et le fichier core et je tape la commande magique bt (comme backtrace) et là, il m'affiche la pile d'appel avec toutes les lignes dans les fichiers qui vont bien.

Mouai. En fait, non, c'est pas imbitable. Je sais, mon argument est aussi puissant que le tiens, mais sincèrement, j'ai l'habitude de faire de petites (et nombreuses) classes, et d'être strict avec les contrats des méthodes/fonctions: si un param d'entrée me va pas, je lance une exception avec un message d'erreur. Vu que je ne rattrape que rarement mes exceptions (et pas toutes, en plus, histoire que ça crash bien comme il faut) quand j'ai un bug je sais très très vite d'où ça viens, même sans débuggueur. Ça m'évite la plus grosse part des douleurs.

Et ça marcherait pas aussi bien avec un assert ? Personnellement, j'en mets des tonnes partout où je peux. et quand ça crache via un assert, ça me crée un fichier core et je peux connaître la stack trace via gdb (c'est d'ailleurs ma seule utilisation de cet outil).

c'est (étonnamment ?) toujours très motivant d'être remercié, surtout dans le domaine du développement open source.

C'est aussi la seule chose qu'on peut faire en remerciement du temps consacré. Et ça me paraît tout à fait normal de citer ceux qui contribuent.

À ce sujet, je note une petite faute sur mon prénom ;)

Ha oui, il va falloir attendre qu'un modéro repasse dans le coin (mais c'est pas gagné, la news a maintenant un certain âge).

Oui, il me semble avoir entendu dire qu'il y avait un gros refactoring sur Ogre pour le faire plus Data Oriented, ce qui pour le coup, faciliterait grandement son utilisation dans un système à entités.

En préliminaire à ces nombreuses questions, je pense qu'il y a une erreur à ne pas commettre : faire rentrer tout dans un système à entité. Et plus particulièrement, je pense qu'il n'est pas possible (ou souhaitable) d'utiliser un système à entité en conjonction avec un moteur de jeu. Parce qu'un moteur de jeu impose souvent une manière de faire qui n'est pas celle des systèmes à entités. Il existe des moteurs de jeu fondés sur les systèmes à entités (comme Unity), et ceux-ci utilisent le concept pleinement. Dans le cas d'Ogre, je crois qu'il va être difficile de le faire entrer dans un système à entité. Ou alors, il faut reprendre quelques classes de bases et refaire les classes haut niveau avec un système à entité, mais tu vas te retrouver à dupliquer du code existant par ailleurs.

Ceci étant dit, je vais essayer de répondre à tes questions.

En premier lieu, comment gérer la surcouche "matérielle" entre les composants de son propre système à entités et une bibliothèque externe ?

Comme indiqué, c'est difficile voire non-souhaitable de le faire, à partir du moment où la bibliothèque externe est assez haut niveau (comme un moteur de jeu complet). En revanche, pour des bibliothèques bas niveau (comme les moteurs physiques, ou les bibliothèques multimédias), c'est un travail d'encapsulation assez classique.

Est-ce que je prends le problème de travers et devrais fusionner ces deux objets ?

Tu prends le problème à l'envers. Il est compliqué de faire rentrer un cube dans un cercle.

Ce serait comme essayer d'appliquer la gravitation à une quête. Peut-on ignorer ce cas de figure, ou est-il raisonnable de penser qu'un composant doit être accompagner d'informations d'antériorité qui doivent être satisfaits pour permettre son existence ? Est-ce hors-sujet pour un système à entités ?

Alors là, je vais te citer un passage d'un article de référence qui dit : «Do Cameras shoot people? Do Bullets accept input from the player? No?» Et en fait, la réponse peut être oui. Donc en gros, les systèmes à entités permettent d'appliquer n'importe quel comportement à n'importe quel entité. Donc pourquoi pas appliquer la gravitation à une quête ? (Bon, ok, dans ton cas, je ne vois pas bien ce que ça voudrait dire). Mais plus concrètement, un object qui a une position n'a pas toujours un corps physique, mais l'inverse n'est pas vrai. Donc évidemment, si une entité a un corps physique, elle doit avoir une position. Et oui, tu peux faire cette supposition. Comme tu le soulignes après, un système n'agit pas sur n'importe quelle entité, il prend en compte le fait qu'une entité possède ou pas un certain nombre de composants.

Mais qui doit s'occuper de la "préparation" de ces cubes, c'est-à-dire notamment créer les objets Ogre à l'intérieur, puis placer correctement tous les cubes selon une scène pré-déterminée d'un fichier de sauvegarde ?

Ça peut être un système, ça peut être à l'initialisation. Généralement, le mot-clef qui va avec ce genre de chose pour les systèmes à entités, c'est «archétype». Un archétype, c'est une fonction qui va générer une entité d'un certain type en lui ajoutant tous les composants qui vont bien. Ces archétypes peuvent être appelé de n'importe où, y compris depuis un système (puisque c'est là que se situe tout le code). Après, la manière dont est créé l'entité dépend du type d'entité. Oui, il faudra peut-être aller lire un fichier de configuration, ça ne change pas grand chose.

Qui doit s'occuper du nettoyage lorsque les composants seront déconstruits (fuite mémoire, notamment) ? Si un composant n'est qu'une structure de donnée sans logique (dans la limite du C++), qui doit s'occuper de ce genre de traitements préparatoires et terminaux ? Un système ? Mais qui l'appellera et quand ? A priori on ne peut pas insérer pareil système préparatoire dans le circuit de la boucle infinie de l'application.

On a vu la naissance, maintenant la fin de vie. C'est un problème différent. Et oui, on peut tout à fait gérer cette fin de vie avec un système spécifique. Dans le tutoriel que j'avais écrit, ça faisait partie des exercices laissés au lecteur. Je conseillais d'ajouter un composant Lifetime avec un booléen indiquant si l'entité est en vie et une fonction à appeler pour détruire l'entité (la fonction inverse de l'archétype). Avec ce composant, on crée un système qui va s'occuper des entités qui possède ce composant. Et à chaque tour, il va appeler les fonctions de destruction sur les entités qui ne sont plus en vie. Après, les autres systèmes vont se contenter d'ajouter un composant Lifetime à une entité s'ils veulent la voir mourir, ou alors il vont positionner le booléen de telle sorte qu'elle meure (cette deuxième possibilité est intéressante dans le cas d'une entité à durée de vie limitée mais dont on connaît la durée de vie à l'avance).

Comment implémenter ce genre de traitement de façon efficace ?

Personnellement, dans ce cas, je ferais appel au moteur physique. C'est lui qui gère les interactions entre entités avec un corps physique. Il sait le faire de façon efficace et normalement, il prévient quand il y a une collision (c'est le cas de Box2D en tout cas).

J'ai du mal à voir comment implémenter le concept de "chose à faire ponctuellement".
Comment dire à un système de modifier un composant *précis *de telle manière *une seule fois ?

Là, le problème est un peu plus large. Et là, ma réponse, c'est que dans toutes les implémentations des systèmes à entités, il y a un systèmes d'événements en parallèle. Ce système d'événements sert justement à «faire une chose ponctuellement». Un système peut alors déclencher un événement et ceux qui sont intéressés par cet événement peuvent alors agir en conséquence.

Le préprocesseur n'a pas été abandonné au profit des templates et const int ce qui rend quasiment impossible l'analyse statique du code et beaucoup de raisonnements élémentaires sur le code source. Résultat: la compilation est très lente dès qu'on sort du cadre d'un projet trivial.

Les compilateurs modernes (dont Clang) savent remonter une erreur jusqu'à l'instruction préprocesseur fautive.

Les références font essentiellement double emploi avec les pointeurs, elles enrichissent le lexique d'un langage déjà touffu pour une sémantique (passage de pointeur sans transfert de propriété) essentiellement dupliquée par les smart pointers.

Les références ne font pas double emploi, au contraire, et elles n'ont pas du tout la sémantique que tu veux leur donner. Et les smart pointers, c'est encore autre chose.

Il est très difficile de tirer correctement parti des champs constants. Bien utiliser l'attribut const nécessite de préparer une vraie stratégie de développement.

C'est une blague ? Il n'y a pas besoin de «stratégie», juste d'un peu de bon sens et normalement, tout se passe bien et les const sont au bons endroits.

Le langage est tellement compliqué qu'il n'y a pas foule de compilateurs implémentant complètement le langage — la dernière fois que j'ai fait des recherches là-dessus il y en avait exactement un. Et puis les implémentations sont boguées! J'ai appris C++ et exactement 3 mois plus tard j'ai découvert un bogue dans le compilateur!

C'est là qu'on voit que tu n'as sans doute pas pratiqué C++ depuis un moment. Certes pour C++98, seul Comeau C++ implémentait la norme complète et en particulier le mot-clef export. Mais celui-ci a été enlevé de C++11 et depuis, Clang et GCC implémente la norme complètement. Après, si tu connais des compilateurs (peu importe le langage) sans bug, dis le, ça va intéresser plein de gens.

En fait, il faut qu'on se cotise pour offrir à devnewton un ordinateur qui gère un truc aussi moderne qu'OpenGl ES 2 pour qu'il arrête de vouloir des bibliothèques qui utilisent encore OpenGL 1 parce que ses cartes graphiques ne gèrent que ça.

Ha tiens, il faudra que je réessaie pour mon jeu. Il y a eu des mises à jour de Mingw-W64, ça va peut-être corriger le bug que j'ai eu la dernière fois.

La réalité, c'est que malgré tout ce que tu racontes, Debian est une des distributions avec le plus de paquets. Dingue, non ?