rewind a écrit 3425 commentaires

Oui, j'y serai pour parler de Gamedev Framework (gf) !

https://fr.wikipedia.org/wiki/Effet_Dunning-Kruger

J'ai hâte de voir un moteur de rendu web simple et KISS.

Houla, ce n'était pas une mise en cause de ton travail. Dans l'ensemble, la dépêche est très bien. J'ai juste dit «cette section» c'est-à-dire grosso modo 5 lignes sur tout l'ensemble. Ça va, c'est raisonnable.

Et puis, je n'avais pas vu cette dépêche dans la liste des dépêches en rédaction collaborative. Je ne regarde pas tout le temps et je dois dire que si je l'avais vu, je n'y aurais pas participé parce que je me sens complètement nul sur ce sujet (j'ai appris plein de choses en la lisant).

Justement, j'ai trouvé cette section très pauvre et mal documentée. Certains jeux flash sur le web sont très populaires (par exemple, Forge of Empires, 14 millions de joueurs selon Wikipedia) mais il n'en est pas du tout fait mention dans la news.

Du coup, j'ai regardé hier soir. Pour un moteur simple, le moteur physique Arcade de Phaser est quand même assez complexe, je trouve. 1214 + 355 + 1788 sloc (donc sans les commentaires), ça fait quand même pas mal. Les seules simplifications par rapport à Box2D, c'est qu'il n'y a pas de joints. Je crois que tout le reste y est.

Je préfère tout intégrer qu'avoir des greffons. C'est un framework, c'est le principe d'avoir plein de briques de base. Je vais voir ce que je peux faire, je vais jeter un œil du côté de Phaser pour savoir comment ils modélisent leur truc. Mais ça me semble faisable sans que ça devienne un vrai moteur physique complet.

Haaa ! En fait, je ne mettrais pas tous ces cas là dans le même panier.

Par exemple, pour les jeux à gravité nulle (en vue de 3/4 ou vue de dessus typiquement : ARPG, Shoot Them Up, etc), une simple détection de collision suffit. Pour Huaca, j'ai uniquement utilisé la détection de collision déjà présente dans gf en modélisant les murs, le héros et les objets avec des rectangles alignés sur les axes. Par exemple, pour les murs, si le héros entre dans un mur, je déplace le héros hors du mur. Je n'appelle pas ça de la physique vraiment, et ça suffit amplement. Il peut y avoir des cas un peu plus complexes où tu dois avoir des rectangles non-alignés sur les axes. J'avais fait un jeu où il y avait une voiture qui se baladait dans un décor, il m'aurait fallu une collision entre forme convexe quelconque, je ne l'avais pas donc j'ai pris Box2D. Mais pareil, ça peut se régler uniquement avec de la détection de collision en première approximation.

Pour les jeux à gravité non-nulle (typiquement les plateformers), il y a un peu plus de boulot mais guère plus. Si tu veux un truc ultra-simple, tu dois juste appliquer les lois de Newton (huhu) à ton héros et faire le calcul à chaque tour de boucle, c'est à peu près 3 lignes à ajouter, pas vraiment besoin d'un moteur physique, je suis d'accord. Tu peux même faire que ton héros traverse les plateformes en montant en vérifiant juste la direction de la normale qui est renvoyée par ta collision. Je peux éventuellement faire un tutoriel là dessus, ça peut être une bonne idée tiens.

Non, pas directement.

En revanche, je vais essayer d'intégrer des algorithmes de détection de collisions. Il y a déjà les plus basiques (cercle/cercle, rectangle/rectangle, cercle/rectangle), j'aimerais ajouter la collision entre deux polygones convexes quelconques (l'algorithme GJK). Je pense que ça peut permettre de faire pas mal de choses déjà. Mais pour toute la partie simulation physique, je ne me sens pas compétent. Et à titre personnel, je préfère utiliser Box2D si j'ai une simulation complexe à faire. D'ailleurs, je ne vois pas bien ce que peut être un moteur physique arcade.

Oui, il y a une raison, je l'avais expliqué un peu dans la dépêche. La raison principale, c'est le conservatisme du principal mainteneur sur les évolutions possibles (y compris des évolutions triviales) et le fait qu'il refuse d'accepter que SFML est utilisée à 99% pour des jeux (et donc il refuse tout ce qui est lié à la programmation des jeux).

J'ai oublié le principal : mettre quelques liens vers le projet !

• le code source sur github
• la documentation en ligne de la version 0.2.0

Du coup, j'ai voulu faire un tour pour voir à quoi ça pouvait ressembler le code de Ryzom et notamment ce bout de code pour les mots de passe. J'ai été incapable de trouver le dépôt, s'il existe. J'ai fouillé pendant 10 minutes sur tous les sites Ryzom sans trouver quoi que ce soit. Y a-t-il un dépôt public ou c'est moi qui suis trop mauvais ?

préférez l'ICIJ

Le partenaire de l'ICIJ en France, c'est Le Monde, qui est tenu, comme quasiment tous les autres journaux, par des millionnaires. Tu crois vraiment que tu reçois une information honnête et impartiale de la part du Monde ? Je prends le dernier exemple en date, les Panama Papers : aucun américain cité dans les articles du Monde. Pourtant, je pense qu'il y en avait des américains dans cette liste (et dans d'autres pays, comme l'Allemagne, ils ont été cités). Beaucoup de gens ont demandé à ce que la liste complète soit rendue publique (et ça a été fait) parce qu'il y a un gros déficit de confiance envers les journalistes, d'où qu'ils viennent. Et d'ailleurs dans ce cas de figure, ça me semble impossible de ne pas donner d'informations nominatives.

Bref, je ne me prononcerai pas sur Wikileaks, je pense qu'il y a à dire sur leurs méthodes, mais dire qu'il faut préférer des journalistes aux ordres de leurs patrons millionaires, et qui divulguent les informations quand ça les chante, et au fur et à mesure pour amener des clics sur leurs sites, non merci. Les méthodes des uns n'ont pas l'air de valoir mieux que celles des autres.

En fait, il dit que, de nos jours, les fonctions de hachages cryptographiques dédiées au hachage des mot de passe ne sont plus les mêmes que celles utilisées pour, entre autre, l'intégrité des données (comme SHA), notamment parce que les secondes ont pour but d'être le plus rapide possible tandis que les premières peuvent (et même doivent) être suffisamment lente pour gêner une recherche exhaustive. Et donc, une recherche sérieuse de 5 minutes sur Wikipédia aurait donné une liste de fonctions adéquates (genre bcrypt ou Scrypt), prenant en compte nativement un sel suffisamment long (qui empêche les attaques de type table arc-en-ciel) et des paramètres comme un nombre d'itération qui vont allonger le temps de calcul de la fonction (qui empêche donc des attaques par force brute, y compris sur des petits dictionnaires). Voilà (j'ai eu la flemme de wikipediser ce paragraphe mais ça aurait été cool) !

on demande d'avoir dans la bibliotheque standard, une operation vector::erase_at(size_t idx)

Je vais me répéter mais cette opération ne sert à rien ! Toute la bibliothèque standard fonctionne avec des itérateurs et donc il est logique d'avoir un erase à base d'itérateurs et pas à base d'indice. Autre avantage, ça permet d'avoir une API unifiée pour tous les conteneurs (dont la plupart n'ont pas le concept d'indice, ou alors pas avec un accès aléatoire). Je veux bien que tu me cites un cas pratique de l'utilisation d'une telle fonction avec un exemple suffisamment long pour être pertinent.

Au passage, la règle pourrait bien être que les destructeurs d'une classe qui a au moins une méthode virtuelle sont virtuels. Ou de définir un mot clé "nonvirtual" pour les 0.01% des cas où on veut explicitement éviter la création d'une vtable.

Ce n'est pas 0.01% mais bien plus puisqu'en C++, les struct et les class, c'est la même chose (à la différence que dans une struct, la visibilité par défaut est publique tandis que dans une class, la visibilité par défaut est privée). Donc, toutes les structures issues de bibliothèques C (donc utilisables en C++) sont concernées. Or, en C, pas de vtable. Il est donc parfaitement impensable d'avoir comme comportement par défaut que tout est virtuel et qu'on dit ce qui ne l'est pas puisque ça briserait complètement la compatibilité avec le C.

Et pour les cas où il faut un destructeur virtuel, -Wdelete-non-virtual-dtor est là pour émettre un message d'erreur si on a oublié.

De renvoyer un bool et d'avoir un std::vector<std::string>const& en entrée?

Je pense que dans ce cas là, on utiliserait plutôt des std::string_view (qui ont juste un pointeur et une taille, donc pas d'allocation) plutôt que des std::string. Malheureusement, il n'y a pas d'équivalent pour les tableaux.

Du coup, tu peux les corriger avec des faits? C'est plutôt ça qui serait utile.

Comme ici par exemple, où je t'ai donné une réponse technique qu'on peut retrouver là ou encore là. Bref, je n'ai pas donné mon opinion, j'ai juste relaté le pourquoi du comment en relayant l'explication quasi-officielle. Et pourtant, cette réponse est à (+1/-2). Tu crois vraiment que je vais continuer pour me prendre des (+1/-2) et au passage m'entendre dire dans la suite des commentaires qu'en fait, ça devrait être simple. Ben non, j'arrête là et tant pis.

Pourquoi es-tu si sensible ?

Parce que je deviens vieux et irascible beaucoup plus facilement.

Que les commentaires de cette dépêche ne te plaise pas, c'est pas grave. Il y a toute une série de dépêche et c'est le langage qui a le plus de journaux. Tu aura pleins d'occasion de discuter de sujets qui te plaisent plus en restant autour de ton langage.

Parce que tu crois vraiment que le fait de voir débouler sur un journal ou une news qui parle de C++ tout un tas de gens qui viennent t'expliquer que Rust/Go/whatever c'est vachement mieux et que t'as rien compris si tu utilises encore C++, ça incite à faire des journaux ou des news sur C++ ? Et bien non, je me dis que j'ai mieux à faire ailleurs, que ça serait une perte de temps.

Maintenant, que tu n'aime pas Rust, c'est ton droit le plus complet.

Ce n'est pas que j'aime ou que je n'aime pas, je m'en fous.

Par contre, sortir des attaques ad hominem comme dans tes autres commentaires et pré-supposer que tes interlocuteurs sont des billes en C++, c'est un manque de courtoisie des plus élémentaires.

Je ne suppose rien, je lis des choses qui sont inexactes et qui servent de base à des dénigrements contre C++. J'en corrige certaines mais je n'ai malheureusement pas le temps pour faire une passe complète. Et quand je lis autant d'approximations, je me dis que les auteurs ne doivent pas être de fin connaisseurs de C++ et qu'ils feraient mieux de ne rien dire. Est-ce qu'exiger qu'on se renseigne un minimum avant de sortir des âneries, c'est devenu un prérequis trop important, même sur linuxfr ?

Je suis peut-être exigeant là-dessus, mais entre vec.erase(vec.begin() + 32); et vec.delete_at(32), je trouve le second bien plus lisible. Et je trouve d'autant plus dommage que le second ne soit pas dans la stdlib au vu de sa facilité d'implémentation.

Sauf que c'est complètement inutile parce que, par exemple, tout un tas d'algorithme générique renvoie des itérateurs (ou des couples d'itérateurs pour marquer le début et la fin d'un intervalle) genre std::find et donc, si tu veux effacer ces éléments, tu es bien content d'avoir erase et ton delete_at serait parfaitement inutile.

De ce que je vois, c'est une “optional technical specification”.

Tu vois mal, c'est marqué en haut dans un cadre avec un gros I devant: «Merged into ISO C++. The functionality described on this page was merged into the mainline ISO C++ standard as of 3/2016; see the filesystem library (since C++17)» avec un lien direct vers la bibliothèque de C++17.

Le comparer à Rust est assez logique puisqu'il se pose en C++-killer, même si ça peu peut être fatiguer.

Voilà, tout est dit, merci.

Pour reprendre tes mots, arrête de venir nous pomper l'air et fait un thread pour mettre en avant ce que nous aimons dans le C++.

Je ne suis pas un VRP de C++, je n'oblige personne à croire que c'est le langage parfait. Je fais des journaux de temps en temps pour ceux que ça intéresse et basta.

Plusieurs personnes ont fait des commentaires sur la complexité du C++ et disent pourtant travailler avec tous les jours.

Oui, mais plusieurs personnes ont fait des commentaires sans vraiment savoir de quoi elles parlaient. Juste des on-dit, des trucs qui datent de plus de 10 ans, etc. C'est saoulant, vraiment. Et surtout, c'est systématique sur les dépêches ou les journaux traitant de C++. Tu pourras refaire l'historique, mais quasiment à chaque fois, il y a quelqu'un pour venir nous parler de Rust. J'ai envie dire : faites des dépêches sur Rust pour parler de Rust, et arrêtez de venir pour pomper l'air pour nous expliquer que C++ c'est de la merde. Chacun est quand même libre d'utiliser le langage qu'il veut. Moi je vis très bien avec C++, ça me va et ce n'est pas les pseudos-arguments des détracteurs qui vont me convaincre. Oui C++ a des défauts, quel langage n'en a pas ? Si le langage parfait existait, ça se saurait depuis longtemps. Et ces défauts, ils me vont bien, je considère même que certains sont des avantages ! Bref, le dénigrement systématique de C++, surtout par des gens qui ne le pratiquent pas, ça me gonfle.

des mécanismes pourtant basiques ne sont pas inclus dans le standard, par exemple les directives préprocesseur pour éviter d'inclure plusieurs fois les headers

Absolument rien n'est basique dans ton exemple. L'existence de liens symboliques et durs fait que ton #pragma once peut te péter à la gueule sans crier gare, sans parler de deux fichiers identiques qui seraient dans deux endroits différents. Bref, si ce n'est pas standardisé, c'est que ces problèmes ne pourront sans doute jamais être résolus de manière sûre. D'autant plus que s'il y a des include guard, les compilateurs sont suffisamment intelligents pour ne pas les réinclure dans les bons cas.