Le topic de la programmation, string, chaînes, cuir et compagnie

[GrandFather]

SQLite, c'est très bien pour du prototypage ou pour des sites à faible volume de données et pas trop exigeantes sur le plan de la fiabilité (pas de support des transactions) et des performances (base de données au format fichier). Si ton site a du succès, ce que je te souhaite, tu seras vite obligé de te rabattre sur du sérieux, comme PostgreSQL.

[Tomaka17]

Je ne crois pas que ce soit pour du web.

[Frypolar]

Ouais pour le moment c’est plutôt perso, pour m’amuser un peu. On verra par la suite mais je me vois mal gérer un site.

[deathdigger]

Ben si tu comptes faire en sorte que d'autres joueurs ajoutent des infos dans ta bdd, je te conseille vivement de ne pas passer par une base embarquée, mais de taper direct dans du mysql : ça sera beaucoup plus efficace qu'avec les bases embarquées, et tu n'auras pas de problèmes de "versionning" de base (en gros que chaque joueur ait sa propre base).
Après, tu tapes en php avec un petit site vite fait, et l'affaire est jouée

[Møgluglu]

Tiens ce serait pas mal que dans le prochain standard C++, on ait une certaine forme d'overloading de fonctions pour certaines constantes.

Bof. Soit tu fais un traitement foncièrement différent dans les versions spécialisées avec des constantes et dans la version générique, et alors bonjour l'intuitivité et la composabilité quand rotate(90.0) et double r=90.0;rotate(r) ne font pas la même chose.
Soit tu fais la même chose avec juste des optimisations pour les cas particuliers, et ça reproduit juste (mal) la spécialisation de fonction et la propagation de constantes du compilo au niveau langage. À la limite, si le compilo est vraiment crétin, on peut l'aider avec des pragma.
Sinon, autant ressusciter auto, register, inline...

Ou alors, je veux bien un exemple d'usage où ça apporte quelque chose et où le compilo ne serait pas capable de faire aussi bien tout seul.

[rOut]

Ressuciter auto ? Je crois que les zombies sont déjà en marche.

---------- Post added at 00h47 ---------- Previous post was at 00h45 ----------

Tiens, d'ailleurs moi je cherche un moyen pour vérifier à la compilation qu'une fonction n'est utilisée qu'avec certaines valeurs entières dans une liste de valeurs entières autorisées pour un paramètre donné...

Faire un enum class, c'est une possibilité, mais ça oblige l'utilisateur à écrire le nom de l'enum partout, et j'ai un bon nombre de fonctions qui n'acceptent pas toutes la même liste de valeurs... Donc il faudrait que je fasse plein d'enums différents, avec des listes différentes et des noms différents, et c'est quand même super laid.

[Frypolar]

Ben si tu comptes faire en sorte que d'autres joueurs ajoutent des infos dans ta bdd, je te conseille vivement de ne pas passer par une base embarquée, mais de taper direct dans du mysql : ça sera beaucoup plus efficaces qu'avec les bases embarquées, et tu n'auras pas de problèmes de "versionning" de base (en gros que chaque joueur ait sa propre base).
Après, tu tapes en php avec un petit site vite fait, et l'affaire est jouée

Les joueurs n’ajoutent pas d’infos directement dans la BDD, enfin n’ajouteraient pas puisque ce n’est pas encore vraiment prévu. L’idée ce serait plutôt qu’ils stockent les données dans un fichier formaté comme il faut et que je le décortique après. D’une part je ne les connais pas donc j’ai pas hyper confiance dans leur sérieux. D’autre part c’est pour Firefall, encore en beta et l’écran de crafting est un poil mal branlé Genre pour deux objets quasiment similaires, avec le même type d’attributs, le premier affichera "blabla : + X %" alors que sur le deuxième on aura "blabla : Y" où Y est proche de 1, genre 0.97, donc un pourcentage mais tu ne sais pas par rapport à quoi. Donc il faut repasser derrière pour vérifier les données fournies sinon ça va tout casser !

[Tomaka17]

Tiens, d'ailleurs moi je cherche un moyen pour vérifier à la compilation qu'une fonction n'est utilisée qu'avec certaines valeurs entières dans une liste de valeurs entières autorisées pour un paramètre donné...

Faire un enum class, c'est une possibilité, mais ça oblige l'utilisateur à écrire le nom de l'enum partout, et j'ai un bon nombre de fonctions qui n'acceptent pas toutes la même liste de valeurs... Donc il faudrait que je fasse plein d'enums différents, avec des listes différentes et des noms différents, et c'est quand même super laid.

Si tu veux faire le check à la compilation, faut forcément que tu passes la valeur comme paramètre template.

Et après tu peux faire un truc comme ça :

template<int N>
auto maFonction()
    -> typename std::enable_if<(N % 2) == 0>::type
{
    // autorisé si N % 2 == 0
}


// ça c'est pas obligatoire, mais ça va te mettre un message d'erreur plus joli :
template<int N>
auto maFonction()
    -> typename std::enable_if<(N % 2) != 0>::type
= delete;

[deathdigger]

Les joueurs n’ajoutent pas d’infos directement dans la BDD, enfin n’ajouteraient pas puisque ce n’est pas encore vraiment prévu. L’idée ce serait plutôt qu’ils stockent les données dans un fichier formaté comme il faut et que je le décortique après. D’une part je ne les connais pas donc j’ai pas hyper confiance dans leur sérieux. D’autre part c’est pour Firefall, encore en beta et l’écran de crafting est un poil mal branlé Genre pour deux objets quasiment similaires, avec le même type d’attributs, le premier affichera "blabla : + X %" alors que sur le deuxième on aura "blabla : Y" où Y est proche de 1, genre 0.97, donc un pourcentage mais tu ne sais pas par rapport à quoi. Donc il faut repasser derrière pour vérifier les données fournies sinon ça va tout casser !

Explique peut être plus le process :
- Si les utilisateurs saisissent dans une base qui leur est propre, comment tu comptes rapatrier les bases pour pouvoir les étudier ?
- Si tu veux vérifier, est-ce que tu veux aussi rebalancer derrière les correctifs à tous les joueurs ou juste à celui qui a saisi ?
- Pour l'écran de crafting, tu parles de celui du jeu directement ?

[Frypolar]

Explique peut être plus le process :
- Si les utilisateurs saisissent dans une base qui leur est propre, comment tu comptes rapatrier les bases pour pouvoir les étudier ?
- Si tu veux vérifier, est-ce que tu veux aussi rebalancer derrière les correctifs à tous les joueurs ou juste à celui qui a saisi ?
- Pour l'écran de crafting, tu parles de celui du jeu directement ?

Là tout de suite la BDD est pour moi. Je suis un connard égoïste qui veut s’amuser un peu à trifouiller là-dedans. Comme je ne vais pas me farcir toutes les classes du jeu à monter lvl X, enfin pas tout de suite , si jamais j’en venais au point de faire une base générale, à ce moment je demanderais probablement à d’autres joueurs de me fournir les données des classes que je ne joue pas. Ce sera via un fichier qu’il leur faudra remplir. Un tableau excel ou un fichier texte bien formaté, je ne sais pas mais ils me fournissent juste les données brutes. À moi de regarder la tête que ça a pour ensuite les ajouter à la BDD. Si jamais je fais un truc public ce sera plutôt une sorte de simulateur car je serais arrivé à trouver les formules qu’il y a derrière le crafting grâce aux données récoltées. Mais les gens n’auront jamais un accès direct aux données pour deux raisons.

La première est que la quantité de données à fournir ne serait pas énorme. Dans Firefall le mécanisme de crafting d’équipement est très très simple. Tu débloques des recettes dont l’unique composant est du minerai. Un seul type de minerai. C’est ce minerai qui va influer sur les caractéristiques de ton objet crafté. Seulement des minerais il y en a 9 types de prévus et au sein de chacun de ces types il y a des variantes, appelées isotopes, caractérisées par un numéro allant de 1 à 1 000. Plus le nombre est grand, plus l’effet du minerai, positif ou négatif, est fort. Un joueur ne va donc pas passer en revue 40 objets possibles avec toutes les variantes de minerai qu’il a en stock sinon il en aurait pour très longtemps. Si jamais ça se fait, ce serait plutôt du genre 1 joueur = 10 objets testés avec quelques types de minerai. Le lien entre le minerai et les caractéristiques de l’objet n’est pas très caché a priori. Je n’ai pas fait les calculs pour vérifier mais on nous donne les attributs du minerai (genre conductivité, dureté et compagnie) et la sensibilité en % de chaque caractéristique vis-à-vis de ces attributs. Par exemple, je dis n’importe quoi, la vitesse de rechargement dépend à 50% de la conductivité, 40% de la dureté et 10% de la densité. Ça c’est clairement affiché en jeu. Ce qui n’est pas dit c’est comment varient vraiment les attributs d’un minerai en fonction de son isotope. Toute la suite du calcul est à peu près claire.

Le deuxième soucis c’est ce "à peu près claire". Pour deux variantes d’un même objet, par exemple un simili lance-roquette, les informations affichées peuvent être différentes. Si je prends la version Astrek du lance-roquette, je raconte encore n’importe quoi, tu vas lire sur l’écran de craft, sans mettre de minerai donc l’objet à poil, que l’aire d’effet de la roquette est augmentée de 8% mais tu ne sais pas par rapport à quoi. Quand tu rajoutes un minerai au craft ce % va varier. Maintenant je prends la version Omnidyne-M du même lance-roquette. Cette fois, en face de "Aire d’effet" il y a écrit "0.97". Rien d’autre. On devine que c’est un coefficient et comme j’ai eu la chance d’avoir un type de minerai qui fait passer cette valeur à 1 j’ai pu trouver ce qu’il y avait derrière. C’est pas compliqué mais le jeu est en vrai beta donc si jamais d’autres joueurs fournissent des données je suis obligé de repasser derrière pour vérifier.

Enfin pour le moment c’est juste pour ma pomme. J’envisageais juste le cas où ça servirait à d’autres histoire de pas avoir à recommencer à zéro

[Tomaka17]

Jsais pas si t'as déjà fait de la base de données, mais vu que ton truc a l'air relativement complexe, essaye d'avoir les bases de conception de schema avant de commencer, ça va t'éviter de recommencer en plein milieu parce que ce sera devenu trop bordélique.

[TiNitro]

Tiens, d'ailleurs moi je cherche un moyen pour vérifier à la compilation qu'une fonction n'est utilisée qu'avec certaines valeurs entières dans une liste de valeurs entières autorisées pour un paramètre donné...

Faire un enum class, c'est une possibilité, mais ça oblige l'utilisateur à écrire le nom de l'enum partout, et j'ai un bon nombre de fonctions qui n'acceptent pas toutes la même liste de valeurs... Donc il faudrait que je fasse plein d'enums différents, avec des listes différentes et des noms différents, et c'est quand même super laid.

Soit tu t'imposes l'utilisation de constantes et la solution des templates de Tomaka fait l'affaire (et nous savons que tu aimes les templates) et dans ce cas static_assert est ton ami, soit tu n'as d'autre choix que de typer tes données, et des enum class sont encore ce que je vois de plus simple et propre, à défaut d'être ultra élégant....

---------- Post added at 16h11 ---------- Previous post was at 16h07 ----------

Bof. Soit tu fais un traitement foncièrement différent dans les versions spécialisées avec des constantes et dans la version générique, et alors bonjour l'intuitivité et la composabilité quand rotate(90.0) et double r=90.0;rotate(r) ne font pas la même chose.
Soit tu fais la même chose avec juste des optimisations pour les cas particuliers, et ça reproduit juste (mal) la spécialisation de fonction et la propagation de constantes du compilo au niveau langage. À la limite, si le compilo est vraiment crétin, on peut l'aider avec des pragma.
...

Tout d'accord avec Mogluglu, tes fonctions spécialisées sont sans doute des cas particuliers optimisés.
Si ta fonction rotate commence par tester la valeur de l'angle et à appeler la bonne fonction suivant le résultat, il y a toutes les chances que le compilateur inline et optimise correctement. Et en plus, ça a le mérite d'encapsuler l'optimisation à l'intérieur de ta fonction, et de ne pas pourrir l'interface avec les cas particuliers. Enfin je trouve.

[rOut]

Soit tu t'imposes l'utilisation de constantes et la solution des templates de Tomaka fait l'affaire (et nous savons que tu aimes les templates) et dans ce cas static_assert est ton ami, soit tu n'as d'autre choix que de typer tes données, et des enum class sont encore ce que je vois de plus simple et propre, à défaut d'être ultra élégant....

Dans le cas présent, les templates m'embêtent un peu...
Le problème c'est surtout que j'ai plein de fonctions, plein de constantes, et que chaque fonction n'accepte pas tout à fait la même liste de constantes que les autres...
Du coup je vais avoir plein de "enable_if< is_one_of< liste à ralonge > >" et ça va faire moche.
Enfin, l'autre possiblité c'est de laisser ça de coté pour le moment...

[TiNitro]

te reste les assert quoi

[Frypolar]

Jsais pas si t'as déjà fait de la base de données, mais vu que ton truc a l'air relativement complexe, essaye d'avoir les bases de conception de schema avant de commencer, ça va t'éviter de recommencer en plein milieu parce que ce sera devenu trop bordélique.

Oui j’ai prévu de relire ce genre de choses. J’ai des souvenirs mais je préfère être sûr pour effectivement éviter de devoir recommencer en plein milieu. Mais l’organisation m’avait pas l’air très complexe. En fait chaque entité n’influe que sur l’entité suivante dans le calcul. En gros on a une classe (entité 1) qui débloque des recettes (entité 2) qui possèdes des caractéristiques (entité 3) sensibles à certaines propriétés minérales (entité 4). Tu injectes ces propriétés minérales d’un côté via le minerai (entité 5) et ça te donne un objet crafté à l’autre bout. Ça c’est pour le côté simulation, quand je saurais de façon suffisamment certaine comment ça fonctionne. En attendant de connaître les rouages je vais devoir créer une entité recette un peu différente qui comportera en plus la variante de minerai utilisé.

Merci pour le lien, je l’ai mis de côté

[Tomaka17]

(gdb) catch throw
Catchpoint 1 (throw)
(gdb) run configure ../mason
Starting program: C:\Users\Tomaka17\Projets\mason-build\mason.exe configure ../mason
[New Thread 3392.0x16a4]
std::bad_alloc
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
[Inferior 1 (process 3392) exited with code 03]
(gdb) bt
No stack.

Merci gdb, je ne sais pas ce que je ferais sans toi.
Je bloque depuis 30mn sur cette bad_alloc qui vient de je ne sais où. J'en suis presque à suspecter un bug dans mingw.


Histoire de donner des nouvelles quant à mon dependency manager.
Je suis passé au YAML, effectivement c'est pas plus mal, d'autant qu'un document JSON est également un document YAML. Et en plus la lib yaml-cpp est bien foutue (vous m'entendrez pas souvent dire qu'une lib C++ est bien foutue).

C'est bientôt utilisable, vu qu'on peut maintenant mettre un fichier de config comme celui-ci (les répo git sont aussi supportés).
Il va automatiquement trouver un numéro de version qui match celui qu'on demande, télécharger l'archive, la décompresser, et appeller CMake (le seul supporté actuellement) ou par la suite n'importe quel autre système de build.
Evidemment au final le but c'est que la base de données soit aussi autre part que dans le fichier de config.

Le seul problème que j'ai actuellement c'est que j'arrive pas à faire s'exécuter CMake dans le bon répertoire. C'est à dire que je créé un répertoire "curl-7.28.0" qui contient les sources et un répertoire "curl-7.28.0-build" qui doit contenir la compilation.
Peu importe ce que j'essaye, j'arrive pas à faire s'exécuter CMake depuis le second. J'ai essayé de changer le répertoire courrant avec boost filesystem, j'ai essayé de faire deux appels à std::system avec dans le premier une commande "cd", j'ai essayé un seul appel à std::system mais avec un point-virgule qui sépare les deux commandes, y a rien à faire.
Du coup je vais surement devoir coder un truc platform-specific juste pour cette petite tâche de merde.

[rOut]

Et "break std::bad_alloc" ?

[Tomaka17]

En fait j'ai fini par résoudre mon problème.
Je faisais un "contents.resize(file.tellg())", sauf que tellg() renvoie -1 quand le fichier n'est pas streamable ou n'existe pas (ce qui est totalement débile).

Du coup quand le fichier n'existe pas, j'essaye d'allouer -1 octets. Vu que je compile en 32bits, je pense qu'il a pas aimé.

C'est finalement un problème tout con, mais je n'ai aucune idée de pourquoi gdb n'arrivait pas à catcher ça.

Encore une preuve de la supériorité des exceptions et de la connerie qu'ils ont faite de pas les mettre par défaut dans les streams.

[deathdigger]

Quand j'ai vu du yaml pour la première fois, j'ai eu envie de vomir. C'est quoi l'intérêt de ce format par rapport au XML ?

[rOut]

Que c'est lisible ?

Un peu comme l'avantage du restructuredText (markdown ça pue du cul) vs HTML, avec juste un éditeur de texte c'est compréhensible et modifiable facilement.

[Tomaka17]

J'ai jamais aimé les langages qui se basent sur la présentation plutôt que sur une structure solide.

Mais l'avantage du YAML, c'est que si tu écris un truc en JSON le parser YAML va quand même le comprendre correctement.

Tant que les documents restent simples, ça va. Là où ça coince c'est quand il y a une grande hiérarchie.

[deathdigger]

Que c'est lisible ?

Un peu comme l'avantage du restructuredText (markdown ça pue du cul) vs HTML, avec juste un éditeur de texte c'est compréhensible et modifiable facilement.

Tu t'en fous que ce soit lisible généralement, dans la mesure où c'est ton serializer/deserializer qui fait le travail pour toi.
Pour le JSON n'en ayant jamais fait, effectivement, c'est peut être plus mieux

[rOut]

Non tu ne t'en fous pas quand quelqu'un va devoir éditer le fichier.

Pour serialiser des choses, comme par exemple lors d'un échange de données entre process, je veux bien que le XML soit une solution tout à fait valable. Ou même pour des fichier de ressources internes stockés sur disque et édités à l'aide d'un outil dédié (par exemple un model 3D collada).
Mais pour des fichiers de configuration qui sont, par nature, destinés à être édités par un utilisateur, potentiellement via un simple éditeur de texte, avoir quelque chose de lisible va lui faciliter la tâche infiniment.

[deathdigger]

Perso je fais mes configs en xml voire en texte brut (une ligne = une partie de la config), ça me viendrait pas à l'idée de foutre du Yaml dedans (et vlà le mec qui édite, qui fout des tabulations en se disant que ça fait comme les espaces).

[rOut]

Ben il peut mettre des tabs s'il veut, du moment qu'il y a des tabs partout...

[Tomaka17]

Ben le JSON est pas mal pour les fichiers de config.

Ce genre de truc par exemple : https://github.com/symfony/symfony/b.../composer.json
C'est bien lisible, c'est simple à écrire, etc.

Le XML est assez lourd si on compare à ça.

[rOut]

Je trouve ça quasiment aussi illisible que le XML perso. Rien que les '{[]},"' supplémentaires qui ne servent qu'à la structuration des données et qui ne sont pas user-friendly du tout.

En comparaison, en YAML ça donnerait quelque chose de beaucoup plus humain avec des listes de '-' et des ':'

---
name: symfony/symfony
type: library
description: The Symfony PHP framework
keywords:
- framework
homepage: http://symfony.com
license: MIT
authors:
- name: Fabien Potencier
  email: fabien@symfony.com
- name: Symfony Community
  homepage: http://symfony.com/contributors
require:
  php: '>=5.3.3'
  doctrine/common: '>2.2,<2.4-dev'
  twig/twig: '>=1.11.0,<2.0-dev'
  psr/log: ~1.0
replace:
  symfony/browser-kit: self.version
  symfony/class-loader: self.version
  symfony/config: self.version
  symfony/console: self.version
  symfony/css-selector: self.version
  symfony/dependency-injection: self.version
  symfony/doctrine-bridge: self.version
  symfony/dom-crawler: self.version
  symfony/event-dispatcher: self.version
  symfony/filesystem: self.version
  symfony/finder: self.version
  symfony/form: self.version
  symfony/framework-bundle: self.version
  symfony/http-foundation: self.version
  symfony/http-kernel: self.version
  symfony/locale: self.version
  symfony/monolog-bridge: self.version
  symfony/options-resolver: self.version
  symfony/process: self.version
  symfony/propel1-bridge: self.version
  symfony/routing: self.version
  symfony/security: self.version
  symfony/security-bundle: self.version
  symfony/serializer: self.version
  symfony/stopwatch: self.version
  symfony/swiftmailer-bridge: self.version
  symfony/templating: self.version
  symfony/translation: self.version
  symfony/twig-bridge: self.version
  symfony/twig-bundle: self.version
  symfony/validator: self.version
  symfony/web-profiler-bundle: self.version
  symfony/yaml: self.version
require-dev:
  doctrine/data-fixtures: 1.0.*
  doctrine/dbal: '>=2.2,<2.4-dev'
  doctrine/orm: '>=2.2.3,<2.4-dev'
  monolog/monolog: ~1.3
  propel/propel1: dev-master
autoload:
  psr-0:
    Symfony\: src/
  classmap:
  - src/Symfony/Component/HttpFoundation/Resources/stubs
  - src/Symfony/Component/Locale/Resources/stubs
minimum-stability: dev
extra:
  branch-alias:
    dev-master: 2.2-dev
...

[saming]

Hello!

J'ai un petit problème avec SDL et tcc.

Lors de la compilation de test pour voir si tout se passe bien afin de commencer, j'obtient direct une erreur:

In file included from ../main.c:3:
In file included from ../include/SDL.h:30:
In file included from ../include/SDL_main.h:26:
In file included from ../include/SDL_stdinc.h:155:
../include/begin_code.h:86: #endif without matching #if

Voici le code:

#include <stdio.h>
#include <stdlib.h>
#include "include/SDL.h"

int main() {
	return 0;
}

Et la structure:

include/
src/
main.c

Je débute réellement, donc y'a-t-il un problème évident que je rate ?

[rOut]

T'as quoi dans begin_code.h ?

[saming]

Voici le code sur un gist.