rewind a écrit 3434 commentaires

Pour ma part … hum hum (sourire gêné) … je vais avoir besoin de plus de 5 minutes pour aller lire ces histoires de move.

Pour comprendre l'intérêt des move, un petit exemple suffit :

std::vector<double> func() {
  std::vector<double> vec;

  // mettre ici tout plein d'éléments dans vec

  return vec;
}

Avant, la dernière instruction provoquait une copie (sauf si le compilateur était intelligent, parfois) ce qui était idiot vu que vec, la variable locale à la fonction, va disparaître juste après le return. On copiait donc des données inutilement. Du coup, la sémantique move a été introduite et maintenant on peut dire : return std::move(vec); pour signaler au compilateur qu'on veut faire bouger ce vecteur, pas le copier. En interne, ça va juste déplacer le pointeur sur les données, ça ne va pas copier les données, et du coup, ça optimise vachement ton code.

Donc, oui, il faut définir un constructeur et un opérateur d'affectation par déplacement, de manière à pouvoir bénéficier de cette sémantique. Bon, après, dans plein de cas, on peut faire une copie, ça ne mange pas de pain. Mais quand tu as besoin de ça, pour des grosses structures, c'est vraiment génial.

mais est-ce que vous connaissez Ocaml? J'ai l'impression que beaucoup de choses sont en fait hyper simple en comparaison.

J'ai fait un peu de caml dans ma jeunesse donc je ne sais pas si ça compte. Mais le fait que C++ (et d'autres langages d'ailleurs) introduise des concepts et des constructions orientées fonctionelles, ça le fait se rapprocher de langages purement fonctionnel. Maintenant, les deux restent suffisamment loin l'un de l'autre à mon sens.

Mais la syntaxe est restée très homogène. Regarde la syntaxe lambda de C++, où la complexité de certaines définitions quand on commence à manipuler des functor, on est plus dans le même monde.

Je pense que là, c'est une question d'habitude. Personnellement, par exemple, j'ai jamais compris la syntaxe de Perl, chaque fois que j'ouvre un script Perl, je n'ai aucune foutue idée de ce que ça peut faire. Pourtant, ça n'empêche pas certain de trouver Perl génial et bien foutu. Moi, la syntaxe C++, hormis les lambdas au début, je la trouve très cohérente. Et maintenant, même les lambdas, je les trouve plutôt bien intégrés.

J'ai appris le C++ quand tout ce fratras de C++11 n'existait pas (je crois même pas qu'on osait lever une exception à l'époque) et Python en version 1.5.2 . En quelques heures, je me suis mis à niveau en Python. Pour C++, j'ai l'impression que je vais galérer beaucoup beaucoup plus.

Le développement de Python s'est fait sur plusieurs années de manière assez incrémentale. Avec C++, on est passé de C++03 à C++11 (soit 8 ans de gestation) en une seule fois, donc la marche paraît plus haute mais elle ne l'est pas à mon sens.

Si un jour un tel débat vient sur la place publique, ça finira par un débat entre le bipartisme ou le centrisme, qui est simplement un débat sur la démocratie.

Personnellement, je ne suis ni pour le bipartisme (surtout quand, comme maintenant en France, et depuis longtemps ailleurs, les deux principaux partis sont d'accord sur l'essentiel) ni pour le centrisme (le centrisme, ça n'existe pas en France, ceux qui se revendiquent du centre ont toujours été alliés électoralement et politiquement à la droite, y compris Bayrou le plus à gauche des centristes). Je suis pour le pluralisme des idées et qu'elles puissent toutes être représentées à leur juste valeur, c'est-à-dire proportionnellement aux électeurs qui ont voté pour ces idées, je suis donc pour le vote à la proportionnelle pour toutes les élections, à base de liste paritaire. Ce qui assurerait une juste représentativité des femmes, qui enlèverait l'aspect personnalisant du vote uninominal, et qui permettrait de se concentrer sur des programmes politiques plutôt que sur la couleur des cravates ou les histoires de cul des prétendants au trône de la République. Le vote à la proportionnelle permet de montrer la nuance dans le résultat, ce que ne permet pas le vote uninominal. Et le système de vote actuel permet déjà ça, pas besoin d'aller chercher un truc moisi.

Prenons un exemple : tu as 3 candidats A, B et C. Tu aimes bien A, mais si c'est B, ça te va à peu près, et tu ne veux absolument pas C. Maintenant, si on t'écoute, ton vote serait A:2, B:1, C:-2. Maintenant, mettons qu'avant ton vote, le total soit : A:10, B:12, C:5. Avec ton vote, tu arrives à A:12, B:13, C:3. Donc B gagne. Mais si tu avais voté A:2, B:-1, C:-2, alors le total aurait été A:12, B:11, C:-2. Ton chouchou A arrive en premier et gagne. Du coup, parce que tu as accordé des points à quelqu'un d'autre que ton chouchou, tu le pénalises et tu risques de faire élire ton deuxième choix, ce qui est pour moi paradoxal. Paradoxal parce que tu préfères A à B mais que c'est ton vote qui permet à B de gagner (bien que tu aies placé A avant B). Il n'y a pas ce problème avec la méthode Condorcet par exemple.

Dans le vote de valeur, il n'y a aucun intérêt, si on soutient un candidat, à mettre des notes intermédiaires pour les autres, au risque de les voir passer. Donc, on se retrouve en fait à voter comme maintenant.

C'est le constexpr qui permet cela

Oui, c'est vrai, c'est plutôt le constexpr qui permet ça. Mais même dans ton exemple, tu pourrais avoir des constructeurs constexpr.

donc pas de risque de collision avec un suffixe "h" qui est déjà défini par l'utilisateur.

En fait, dans C++14, il y aura deux suffixes "s" : un pour les secondes et un pour les chaînes. Mais normalement, aucune collision vu que celui pour les secondes s'appliquent à des nombres et celui pour les chaînes s'appliquent… à des chaînes.

Je ne serais pas aussi pessimiste que toi. Certes il y a des évolutions mais, à mon sens, elles vont dans la bonne direction, à savoir écrire des choses puissantes en moins de lignes. Oui, ça crée pas mal de nouvelles syntaxes, mais au final, on s'y habitue assez vite et on les adopte. Les lambdas, au départ, c'est un peu chaud, mais dès qu'on en a écrit soi-même deux ou trois sur des cas assez simples (comme dans un tri avec std::sort), on comprends le truc et on les range dans la catégorie des bons outils à réutiliser.

Après, est-ce qu'il faut les utiliser ? Non évidemment. Les exemples que j'ai pris ici, j'ai vu que ça passait bien et que ça simplifiait les choses, ça permet d'écrire moins de code pour l'utilisateur de la bibliothèque, respectant ainsi l'adage qui dit qu'en C++, écrire une bonne bibliothèque est difficile quand l'utiliser est facile.

L'autre solution avec C++, c'est de se restreindre à un sous-ensemble et d'ignorer le reste. Après, il y a des trucs qui ne coûtent pas grand chose à faire et qui sont utiles pour les autres. Un exemple qui me vient en tête et que j'ai déjà utilisé, c'est d'écrire une méthode begin() et une méthode end() qui renvoient des itérateurs pour des classes qui ressemblent à des conteneurs. Pourquoi ? Parce qu'après, ça permet d'utiliser le range base for (le même que dans Java) sans aucun problème.

J'ai lu avec intérêt ton nouveau message, et en ce qui concerne l'utilisation de std::function et std::bind, j'ai plus l'impression qu'il s'agit d'aides pour simplifier l'écriture de functors.

Tu n'as pas tout à fait tort. Effectivement, ça existe depuis un moment, notamment dans boost, mais maintenant, c'est en standard. Et en plus, ça se couple très bien avec les lambdas, et ça, ça n'existait pas avant. Ça permet de s'éviter du code superflu quand on doit faire une petite fonction et qu'on n'a pas envie de déclarer une fonction à part, ou une classe.

je me demande quelle est la différence entre cela et utiliser une fonction normale

Tout se fait à la compilation plutôt qu'à l'exécution. Ça améliore les performances et ça peut améliorer la lisibilité. Par exemple dans C++14, ils vont introduire les suffixes "h", "min", "s", "ms", "us", "ns" pour créer automatiquement des durées (std::chrono::duration). Ça va permettre d'écrire des choses du genre :

auto total = 1s + 12min + 3h;

Comme quoi les inquiétudes sur le biais en faveur d'Upstart dus à la présence d'employés Canonical n'était pas complètement fondés.

Ou si. Tous les employés Canonical ont voté en bloc pour Upstart, ou du moins pour barrer la route à systemd. Dans quelle autre distrib communautaire s'est-on posé la question d'Upstart à ce point ? Aucune. Et ça, ça vient bien du fait qu'il y ait des employés Canonical dans le ctte.

son commentaire était tout a fait pertinent

Tellement pertinent qu'à l'heure où j'écris, il est à 0. Comme quoi je ne dois pas être le seul à avoir réagi de cette façon.

Ma boutade n'est pas sur le fond mais sur la forme. Tu admettras quand même que Zenitram est un peu culotté de dire qu'il ne lit pas l'article mais après, il va faire 50 commentaires dont celui auquel je réponds. Mais à propos de quoi puisqu'il ne lit pas l'article ? Donc, je fais comme lui, je vais me permettre de critiquer mais je ne vais pas lire ce qu'il écrit. Il ne m'en voudra donc pas. Il aurait pu expliquer ce que tu dis, calmement et ça serait sans doute mieux passé.

Posté par Zenitram

Poubelle. Pas de lecture plus loin.

Quand tu dis qu'il faut être indulgent sur le code, je trouve que tu te dévalorises beaucoup. Tu as le style d'un développeur Java (du coup, tu utilises un sous-ensemble de C++), mais ça fonctionne très bien, le code est très compréhensible.

ça implique quand même de devoir réécrire tout un tas de trucs… chez Go, pour les changements de nom dans la lib standard, ils avaient développés un outil pour faire les modifications automatiquement, on en est loin là !

laisse aux développeurs de Rust le soin de choisir quand ils considèrent que le projet est suffisamment cohérent et propre pour être stabilisé.

On ne peut pas dire que ce n'est pas stabilisé et en même temps qu'il faut l'utiliser. Or, c'est exactement ce qui est dit à la fin :

Il y aura encore sûrement des changements dans la syntaxe — et dès la parution du la version 0.9, il y en a déjà, voir This week in Rust du 11 janvier — mais le langage est très proche de la complétion et il commence à y avoir suffisamment de ressources en ligne pour apprendre. Il n’y a plus d’excuses pour ne pas se mettre au Rust ! ;)

Pour moi, c'est incohérent ! Et je préfèrerais qu'ils disent : «OK, il va y avoir des changements de syntaxe importants, on va attendre d'avoir tout remanié et ensuite, on appellera à des tests et si pendant suffisamment de temps, on n'observe pas de besoin de nouveaux changements de syntaxe, on décrétera que c'est figé.»

Java, C, C++ sont dans la première catégorie. Python est à la limite (parce qu'il y a un processus pour normaliser). Donc, je choisis cette catégorie là. Surtout que donner Visual Basic comme exemple du second, je trouve ça particulièrement croustillant, ça donne vraiment envie !

Bon, si on arrête de rigoler deux secondes, tes catégories n'ont aucune signification, il y a des bons et des mauvais langages dans les deux (sous-entendu, des langages pour faire des choses utiles). Et ce n'est absolument pas la question que je pose. Je m'étonne qu'un langage qui a déjà un historique assez long et qui est plutôt sur la voie de la finalisation soit encore si instable au niveau de sa syntaxe. Si on prend Go par exemple, il a convergé petit à petit et les changements de syntaxe ont été de moins en moins invasifs jusqu'à la version 1. Là, on change un des trucs mis en avant depuis le début !

Si on voulait faire un parallèle, on prendrait plutôt les clichés dans les romans. Par exemple, quand tu prends 90% de la littérature de médiéval fantastique, c'est uniquement du cliché vu et revu. C'est lassant, et c'est ça qui est dénoncé. Maintenant, ça ne veut pas dire qu'un énième titre de médiéval fantastique rempli de clichés ne marchera pas.

Il n'y a que moi qui trouve inquiétant qu'un langage qui est en développement depuis plusieurs années et qui s'approche de la version finale à grand pas soit aussi instable au niveau de sa syntaxe ? (et pas uniquement sur des détails en plus). Moi, quand on vient me dire qu'on peut commencer à tester, je fuis immédiatement, parce que je me dis que ce langage risque d'évoluer suffisamment pour que tout ce que j'apprends et je fais soit obsolète dans deux mois… Enfin, c'est l'impression que ça me donne.

Je m'attendais à ce qu'il prétende que le leveling était sans intérêt.

Le leveling (dans le bon sens du terme) n'est pas sans intérêt, au contraire, il permet au joueur de mesurer sa progression.

Je ne pense pas qu'il dise que c'est mauvais comme gameplay, il dit simplement que le game designer n'a pas fait beaucoup d'effort pour imaginer autre chose que le cliché. Maintenant, il pourrait évoquer le pourquoi (c'est-à-dire pourquoi on voit sans cesse les mêmes clichés), et il l'effleure à peine à deux moments dans la suite de la série. Premièrement quand il parle du turnover, deuxièmement quand il parle des FPS qui sont les nouveaux sidescroller.

Son discours est de dire qu'à cause du turnover, il n'y a pas de mémoire et donc, les game designers refont toujours les mêmes bêtises (ce qui est discutable). Et ensuite, il dit que c'est dans les FPS qu'on retrouve la plupart de ce qu'il dénonce et que ce sont les nouveaux sidescroller, sous-entendu il en existe une tétrachiée qui se ressemblent tous comme les sidescrollers dans les années 90. À mon sens, il analyse bien la conséquence mais il ne voit pas la vraie cause qui est l'industrialisation massive du jeu vidéo. Quand il commence sa série, les «gros» studios sont des nains composés de pionniers, avec une technologie très changeante. Aujourd'hui, on a des entreprises énormes, une industrie qui surpasse le cinéma et la musique, des milliards de brouzoufs à engranger ou à perdre. Donc, comme pour le cinéma, on fait ce qui marche et donc, on ne s'écarte pas trop des clichés et de ce qu'il considère comme des mauvaises conceptions. Je pense qu'il n'a pas vu venir l'industrialisation et sa puissance. Alors oui, actuellement, on voit beaucoup de clones et oui, ça se voit dans les FPS, jeux qui s'adressent à la catégorie qui consomme le plus de jeux vidéos : le mâle trentenaire sans enfant avec une profession intermédiaire ou supérieure.

Dans le même ordre d'idée, il parle beaucoup des sauvegardes, de la manière de faire pour que le jeu vieillisse bien, etc. Bref, des trucs de long terme. Mais ça ne peut plus marcher quand on veut sortir une version par an (avec un delta par rapport à l'année d'avant qui va du minimal au négligeable). Dans ce cas là, on s'en fout de bien gérer les sauvegardes, de toute façon, on en ressortira une version l'année suivante. Ça aussi ça vient de l'industrialisation massive : quelques gros titres tirent le reste des jeux qui marcheront moins bien. Mais sans ces gros titres, le reste aurait du mal à survivre. Pareil que dans le cinéma, ou dans la musique.

Donc, quand il dénonce tout ça, il a raison et tort. Raison quand on se place du point de vue d'un fan de jeu vidéo qui aimerait un peu plus de diversité, mais tort quand on examine les raisons économiques qui poussent à l'utilisation de ces clichés. Quand on développe un jeu amateur (et même indie), on doit écouter ces conseils, pour proposer autre chose, parce qu'on ne pourra jamais rivaliser avec un gros studio sur les clichés.

Au contraire, j'ai trouvé ces articles fort pertinents. L'exemple des caisses est vraiment caractéristique. Certes, c'est fondamental au gameplay, mais pourquoi une caisse ? Pourquoi pas un autre objet ? Tout simplement parce que la caisse est l'objet standard qu'on peut mettre partout, tellement standard que ça en devient ridicule parce que ça n'a souvent aucun intérêt dans le contexte d'avoir une caisse. Plutôt que de chercher quelque chose d'identique niveau forme mais avec une vraie raison, les game designers iront au plus vite.

J'ai beaucoup ri sur un des premiers qui décrit comment les RPG transforment souvent le joueur en marchand d'armes d'occasion. Typiquement ce qu'on retrouve dans beaucoup de MMORPG (et pourtant, l'article original date de 1998). Il y a beaucoup d'autres choses qui sont intéressantes quand on programme un jeu, pour éviter les erreurs. Quand on est joueur, effectivement, on ne se rend pas forcément compte de ce que ça peut représenter.

notamment avec cette histoire d'ombre qui m'a réjoui à la lecture (j'ai vu le cowboy marcher au soleil couchant).

pour l'instant, ça tient du rêve, mais ce n'est pas impossible ;) J'y travaillerai quand j'aurai bien avancé sur le reste.

Je voyais les « tuiles » comme des sprites qui une fois posés sur des ancres s'abuttent (s'il n'y a ni angle, ni offset). J'étais naïvement resté sur la composition de paysage pittoresque avec des petits villages de bric et de broc, ou de capitales avec des quartiers huppés construits en dur et tirés au cordeau avec de grandes allées à statues, contrastant avec des faubourgs plus authentiquement bordéliques, voire bidonvillesques.

En fait, si je comprends bien ce que tu dis, tu voudrais construire des cartes uniquement avec des sprites. C'est une idée très intéressante que j'ai déjà vu utilisé pour des sidescroller. L'avantage, c'est qu'on peut avoir des cartes superbes. L'inconvénient, c'est qu'il faut avoir tout un tas de sprite qui se coordonnent bien, qu'on peut redimensionner comme on veut, et que la construction de la carte est moins facilement automatisable.

Je n'avais pas même pensé aux visites d'intérieur, si ce n'est sous l'angle Zelda*, avec une vue « plan d'évacuation ISO machin bien carrée » décorrélée de l'extérieur (décalage de boussole en option ? moyen de faire des tipis ronds quand même… et des cloisons biscornues ? un must pour une bicoque de sorcière…).

Rien n'empêche d'avoir un jeu de tuiles spécifique pour des bâtiments uniques. Mais bon, ça ne compte pas ;)

Je me suis peut-être mal exprimé, je reprends. Tout d'abord, le jeu est en vue de haut (à la verticale), donc on ne voit vraiment que le haut. Ensuite, la carte est basée sur des tuiles, c'est-à-dire un ensemble prédéterminée de petits morceaux de cartes qu'on va assembler pour construire une grande carte. Et le problème il est bien là, c'est que si tu ne peux pas avoir une quantité monstrueuse de tuiles, pour tous les angles possibles, il faut faire des choix sur ce qui est possible, et dans mon cas, ça sera deux ou trois orientations pour le toit (et ça va déjà faire un paquet de tuiles à faire).

L'autre solution, ça aurait été de poser un sprite (une image) de toit, et là, on pouvait le placer comme on voulait, avec l'angle qu'on voulait. Mais d'un autre côté, il fallait faire correspondre exactement le toit et l'intérieur (sur une autre couche), ce qui n'est pas forcément évident à la main. Il y a également d'autres problèmes que je n'évoque pas. Bref, solution plus flexible mais solution plus complexe.

Sans dévoiler de grands secrets, mes sources actuelles d'inspiration sont :

• Red Blog Games et son magnifique tutoriel
• Procedural Content Generation Wiki

Je vais aller voir tes références pour ajouter des sources d'inspiration.