Discussion :

[Trademark]

Bonjour,

À l’occasion d'un projet, je dois coder un serveur. L'échange des données se fait principalement sous cette forme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
[balise1]
  id = IDENTIFIANT
  [info]
    nom = NOM
  [/info]
[/balise1]

On a déjà une classe qui s'occupe de parser ce schéma dans un arbre. Ce que j'aimerais c'est pouvoir valider cet arbre.

Par exemple avoir un schéma comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
[balise1]
  id = REGEX <-- requis
  [info] <-- {0 .. 2}
    nom = REGEX <-- requis
  [/info]
[/balise1]

Ce validateur devrait pouvoir vérifier la répétition d'un champ, par exemple le champ info peut apparaitre de 0 à 2 fois. Et ceci sous d'autres formes encore comme '*', '1 .. *', ...

On controlera les types avec un regex ou éventuellement autre chose suivant.

Et il faudra que le nom des balises et des attributs soient exactement les mêmes.

Plus encore peut-être d'autre choses auxquelles je n'ai pas encore pensé.

J'étais prêt à coder ma propre solution, mais en essayant de faire un design, je me suis demandé si ce n'était pas un peu comme un lexer. Ou s'il n'existait pas des solutions pour ça, vu que ça semble assez banal.

Du coup j'ai un peu regardé Boost.Spirit.Lex mais est-ce que ça n'est pas un peu étrange d'écrire des règles de cette manière pour un protocole réseau ? Et de plus, j'ai l'impression que c'est un peu trop pour mon problème.

N'hésitez pas à me demander plus de détails.

Merci d'avance

[koala01]

Salut,

Je me demande si boost spirit ne te permettrait pas de faire tout cela :

• Spirit Qi est un parser
• Spirit Kama est un générateur (écriture)
• Spirit Lex est un analyseur lexical

Je ne sais pas quel est l'état d'avancement de ton projet ( surtout en ce qui concerne le parsing et l'écriture), mais, peut etre est-il encore temps de prendre une "solution intégrée"

Ouppsss... je m'étais arrêté avant la fin du message et n'avais pas remarqué que tu envisageais effectivement spirit...

Non, pour moi, il n'y a pas vraiment de problème à utiliser spirit pour un protocole réseau, étant donné que, de toutes manières, les informations peuvent être considérées comme un flux de données

De plus, "qui peut le plus peut le moins"... Tu auras plus facile à ne pas utiliser quelque chose de présent qu'à... essayer d'avoir quelque chose qui n'existe pas

[Trademark]

Merci pour ta réponse koala01,

En fait, c'est un projet open-source nommé Wesnoth, qui est un jeu de stratégie au tour par tour.

Ils ont déjà une classe config qui stocke un fichier comme présenté ci-dessus.

Ce qu'il me faut c'est juste la partie "validation".

De plus je me disais, qu'au final, un schéma est quelque chose de statique. J'ai donc envisagé les possibilités les plus folles avec la métaprogrammation et Boost::mpl par exemple. Mais je ne suis pas arrivé à quelque chose de convainquant.

Sachant que Spirit.Lex est totalement dynamique, je me demandais si ce n'était pas une éventuelle perte de performance ?

De toutes manières, les schémas seront créés dès le début, et au final je voudrais juste pouvoir faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
config cfg;
// On récupère du réseau les données dans config.
// ...
 
validator.validate(cfg);
 
// Et dans validator on ferait quelque chose comme :
 
bool validate(const config &cfg)
{
  std::string label = cfg[0];
  if(label == "update")
    return update_validator.validate(cfg);
  else if(label == ...)
  // ...
 
  return false;
}

Ce qui serait statique serait par exemple, update_validator. Mais je ne sais pas comment représenter statiquement update_validator et si ça a un réel avantage.

Qu'en pensez-vous ?

[koala01]

Le fait est que, de toutes manières, le schéma n'est pas validé en permanence...

Typiquement, si c'est un schéma de configuration, tu vas le valider une première fois au moment de charger la configuration et, éventuellement, au moment où tu voudras sauvegarder une configuration modifiée.

Je ne pense sincèrement pas que tu doives réellement t'inquiéter des problèmes de performances dans le cas présent : n'oublie pas que 80 du temps d'exécution est perdu dans 20% du code...

AMHA, les problèmes de performance ne viendront pas d'un endroit qui n'est utilisé que si rarement

[Trademark]

Je pense qu'on s'est mal compris et que le nom de la classe porte à confusion.

La validation va s'opérer à chaque fois qu'on va recevoir un paquet du réseau, pour valider ce paquet. Un paquet est organisé comme présenté ci dessus.

Du coup, les questions de performance peuvent peut-être se poser ici.

[ternel]

Pas vraiment puisque les paquets réseaux n'arrivent qu'à chaque changement de tours, soit toutes les deux minutes et non toutes les secondes.

Alors, si la validation prends quelques secondes, le joueur est en général d'accord pour attendre si peu au changement de tour. (surtout qu'on doit pouvoir réaliser les animations de début de tour pendant ce temps...)