Evaluation d'une expression numérique

Version imprimable

02/01/2011, 19h42
mister3957

Evaluation d'une expression numérique

Bonjour à tous,

Je possède une expression numérique sous forme de chaîne de caractères, par exemple :

Code:

(3*[x] / 2) + (2*[y] /4)

Mon programme va lire cette expression pour remplacer [x] et [y] donnés à l'exécution et renvoyer le résultat.

Seulement l'expression peut devenir complexe au fil du temps et j'aimerai passer par une bibliothèque qui à coup sûr seras plus complexe et performante que ce que je ne peux faire moi même.

Y a-t-il un outils permettant de faire ça en C++ ?

Je vous remercie par avance,

A bientôt
02/01/2011, 20h12
Davidbrcz

Boost::spirit fait ca à merveille !
Pour une réponse plu détaillé, regarde sur le forum avec des termes comme "parsing" ou évaluation d'expression. Le forum regorge de topic similaires.
03/01/2011, 01h05
bretus
Bonsoir,

Ou encore Qt avec son interpréteur ECMAScript (sous ensemble javascript)

Tu arriveras à interpréter ceci :
Code:

1 2 (3*x / 2) + (2*y /4)
Et tu bénéficieras de Math.cos(x) etc...

Voir description détaillée :
http://qt.developpez.com/doc/latest/qscriptengine.html

Avec Qt, tu as au passage un débugger et de la possibilité d'exposer tes propres objets sans trop de mal.

ps :
- on trouve moult autres interpréteurs ECMAScript dont le V8 de Google Chrome
- boost::spirit est une solution de plus bas niveau pour écrire son propre langage en somme. A mon humble avis, permettre de scripter dans un langage existant rend plus de service.
03/01/2011, 08h17
Joel F

Citation:

Envoyé par bretus

- boost::spirit est une solution de plus bas niveau pour écrire son propre langage en somme. A mon humble avis, permettre de scripter dans un langage existant rend plus de service.

Non ... spirit est du C++ ... donc c'est equivalent au truc de QT tout en etant moins lourd en terme de dependances et plus efficace ...
03/01/2011, 11h22
jblecanard

Citation:

Envoyé par bretus

A mon humble avis, permettre de scripter dans un langage existant rend plus de service.

Pas tout à fait d'accord : ça rajoute des dépendances pas forcément faciles à gérer et peut apporter une lourdeur d'exécution pas utile. De plus, linker un autre langage avec C++ (avec Boost.Python par exemple) se fait bien mais c'est assez fastidieux tout de même !

Citation:

Envoyé par Joel F

Non ... spirit est du C++ ... donc c'est equivalent au truc de QT tout en etant moins lourd en terme de dependances et plus efficace ...

Oui, et plus la syntaxe est personnalisable à souhait !
03/01/2011, 13h15
bretus

Bonjour,

Citation:

Envoyé par jblecanard

Oui, et plus la syntaxe est personnalisable à souhait !

Je comprend vos points de vue sur les dépendances, mais en même temps, il faut savoir les accepter. A défaut, on ré-invente un langage de script, on écrit une grammaire et au final, on ne rend pas plus de service avec son interpréteur et sa syntaxe qu'en utilisant un langage et un moteur existant.

En terme de maintenance, je me demande ce qui est le pire : Apprendre à utiliser boost::spirit (où on t'explique en 150 lignes comment on compte "hello" ;) ) ou apprendre à gérer la dépendance à Qt.

Je n'ai pas vu d'interpréteur prédéfini dans boost::spirit et je doute qu'un outil pour écrire des parseurs soit équivalent à un moteur de script. La syntaxe est-elle tellement personnalisable qu'il faut écrire l'intégralité de la grammaire et des mécanismes d'interprétations?

En ce qui concerne le point "fastidieux" de QtScript vis à vis de Boost.Python (ou des interfaces d'accès aux moteurs de script):
- Toutes les méthodes déclarées comme des slots sur les classes dérivées de QObject sont accessibles depuis l'ECMAScript
- Il suffit d'une méthode statique de fabrique déclarée pour "new" pour exposer une classe C++ dérivée dans l'ECMAScript.

Après, voilà, vous êtes libres et le choix dépend comme toujours du contexte de développement.

Pour l'avoir subit, pensez peut-être à la charge de documentation qui suit la mise en place d'une syntaxe et de primitives perso, et surtout à l'engouement des utilisateurs pour l'apprentissage d'un langage mono-usage tel celui de cmake... Ou imaginez un cmake reposant sur un moteur ECMAScript...

Cdlt
03/01/2011, 13h52
jblecanard

Citation:

Envoyé par bretus

Pour l'avoir subit, pensez peut-être à la charge de documentation qui suit la mise en place d'une syntaxe et de primitives perso

Oui enfin, là on parle d'interpréter une simple expression ! Qt comme dépendance pour une chose si simple, c'est quand même lourdingue.

Après pour un vrai langage de script, je suis d'accord qu'il faut utiliser de l'existant.

Citation:

Envoyé par bretus

l'apprentissage d'un langage mono-usage tel celui de cmake... Ou imaginez un cmake reposant sur un moteur ECMAScript..

Je ne crois pas qu'un cmake basé sur ECMAScript me plairait tant que ça. C'est un langage simpliste qui fait bien le seul travail auquel il est destiné. De plus, on mélange les utilisateurs et le développeur là. Les utilisateurs de mister3957 n'auront pas à se préoccuper de ça ;)

Edit : Vu que je sujet m'intéresse, je suis en train d'écrire un interpéteur d'expression math simple avec Boost.Spirit, j'en ferais un tutorial. Si la publication du tuto vous intéresse, envoyez moi un MP. J'ai déjà bien entamé le code.
03/01/2011, 17h28
Joel F

l'evaluation d'expression numerique est genre dans les exemples de spirit ...

mais passons ...
03/01/2011, 17h37
jblecanard

Peu importe, c'est un exercice que je fais pour apprendre à me servir de boost. ça me coûte rien de le partager avec des explications en français.
03/01/2011, 18h41
Jean-Marc.Bourguet

Juste pour mettre un peu de variete dans le debat; pour parser des expressions, je ne passerais pas par un generateur d'analyseurs grammaticaux (et je les connais assez bien, j'en ai ecrits; mais bon, je connais aussi tres bien les techniques pour ecrire des parseurs a la main).

Comme je l'ai deja ecrit dans le passe, les generateurs ne me semblent convenir que pour des grammaires de complexites moyennes; si la grammaire est simple ca ne vaut pas la peine d'y passer -- surtout si on ne connait pas de generateurs -- , si la grammaire est compliquee il y a trop de hacks necessaires(*). Parmi les facteurs qui augmentent leur pertinence: le manque de stabilite de la grammaire, le fait que la grammaire de reference ait ete concue en fonction des generateurs, la familiarite avec le generateur employe, la necessite d'avoir des grammaires definies dynamiquement (ce point rend les generateurs quasiment incontournables :). Parmi les facteurs qui en diminuent la pertinence: la necessite d'avoir des messages d'erreur clairs, le desir de gerer des variantes du langage (la necessite de performance est souvent citee, je n'ai pas d'experience personnelle).

(*) Je me demande a quel point l'introduction de generateurs GLR changent la donne, ils ont ete introduits trop tard pour avoir joue un role dans les parseurs sur lesquels j'ai travaille. Les GLL (et si j'ai bonne memoire la premiere version de spirit en faisait partie) ne la change pas trop: il faut reorganiser une classe importante de grammaire.
03/01/2011, 19h14
Joel F

Citation:

Envoyé par jblecanard

Peu importe, c'est un exercice que je fais pour apprendre à me servir de boost. ça me coûte rien de le partager avec des explications en français.

nana, on a cross-posté, ma remarque ne t'etait pas destinée
04/01/2011, 11h12
jblecanard

Citation:

Envoyé par Jean-Marc.Bourguet

Comme je l'ai deja ecrit dans le passe, les generateurs ne me semblent convenir que pour des grammaires de complexites moyennes; si la grammaire est simple ca ne vaut pas la peine d'y passer

Que conseilles-tu d'utiliser alors dans ce cas ?

Dans la pratique, la question de l'interpréteur d'expression revient souvent, mais la personne est en général quelqu'un qui n'a pas que ça à faire d'apprendre à utiliser Spirit (ou un autre outil) et qui voudrait, si on en connaît un, qu'on lui conseille un outil simple, déjà codé.

L'avantage d'un interpréteur déjà codé avec Spirit est qu'on a pas besoin d'une librairie tierce, puisqu'il n'est composé que de headers. L'intégration dans un projet est donc sans douleur.

C'est le but de l'exercice que j'ai effectué : proposer à ceux qui en cherche un un interpréteur tout fait. Et pour ceux que ça intéresserai, comment il est fait. J'ai quasiment fini le code. L'interpréteur tient en moins de 100 lignes, mais sa compilation est horriblement longue car j'utilise des tas de templates (boost.variant, boost.fusion et boost.spirit évidemment !). J'ai encapsulé ça avec des forward déclarations pour éviter que tout soit recompilé quand on s'en sert dans du code.

Citation:

Envoyé par bretus

En terme de maintenance, je me demande ce qui est le pire : Apprendre à utiliser boost::spirit (où on t'explique en 150 lignes comment on compte "hello" ;) ) ou apprendre à gérer la dépendance à Qt

C'est vrai que ça a été un peu moins simple que ce à quoi je m'attendais, mais je n'ai pas eu besoin d'apprendre à fond spirit et l'interpréteur est très compact en terme de code. Il faut dire que j'ai quelques vieilles bases théoriques en analyse syntaxique, ça m'a bien aidé... ça aurait été vraiment long sinon.
04/01/2011, 12h03
mister3957

Je ne pensais pas que ma problématique allait générer un tel débat ! :)

Pour être plus précis, je travail sur un projet cartographique et je dois gérer les zooms de l'application. A chaque niveau de zoom, cela va solliciter la base de données afin de générer des tiles si ceux-ci n'existent pas encore.

Lorsque l'on est sur une vue à l'échelle mondiale (-180 / +180), certains voudront pour le prochain zoom une division par deux, amenant la longitude affichée à (-90 / +90). En revanche, ce même utilisateur préférera peut-être des échelons de zoom plus "fin" au fur et à mesure qu'il se rapproche de la "terre", par exemple passer de (-2 / +2) à (-1.7 / +1.7) et non sans garder le rapport "/2" employé à l'échelle mondiale.

Les utilisateurs devront donc étalonner la "formule" de zoom selon leurs besoins, leur métier, leur infrastructure matérielle etc. et c'est pourquoi j'aurai aimé que cette dernière soit configurable à l'extérieur du logiciel, donc via une formule sous forme de chaîne de caractères.

Bien évidemment développer et entretenir un tel module, je m'en passerai volontiers surtout que l'an deux mille est passée..

Pour répondre aux différents messages, et je vous en remercie, il est évident que ça m'embêterai fortement de lier mon module cartographique à Qt uniquement pour ça, et par habitude, je préfère limiter mon utilisation de Qt uniquement à la construction d'interfaces graphiques et laisser gérer le reste par d'autres bibliothèques plus évoluée, performante, du moins gratuites comme pour les threads, la programmation réseau, la gestion de la mémoire etc.

Je ne connais pas et donc je vais étudier boost::spirit mais ça ne m'étonne pas que la résolution de cette problématique se trouve une fois de plus dans une des bibliothèques de boost ;)

Citation:

Edit : Vu que je sujet m'intéresse, je suis en train d'écrire un interpéteur d'expression math simple avec Boost.Spirit, j'en ferais un tutorial. Si la publication du tuto vous intéresse, envoyez moi un MP. J'ai déjà bien entamé le code.

Avec grand plaisir, et merci par avance :)
04/01/2011, 12h09
Goten

Citation:

L'avantage d'un interpréteur déjà codé avec Spirit est qu'on a pas besoin d'une librairie tierce, puisqu'il n'est composé que de headers. L'intégration dans un projet est donc sans douleur.

Le vraie avantage, c'est le fait que ça soit un DSEL. Avec en vrac une syntaxe (très) proche de l'EBNF (c'est pour ça que l'histoire du "faut 40 ans pour le maitriser" vous repasserez...), le fait que tout soit déroulé à la compilation et les perfs induites. (suffit de voir comment karma surpasse atoi).

Bon par contre ça a des inconvénients, le bloat (si quand même un minimum), la vitesse de compilation (c'est un faux problème, les gens ont qu'a utilisé des vraies compilo et des PCH)
04/01/2011, 12h48
jblecanard

Citation:

Envoyé par Goten

Le vraie avantage, c'est le fait que ça soit un DSEL. Avec en vrac une syntaxe (très) proche de l'EBNF (c'est pour ça que l'histoire du "faut 40 ans pour le maitriser" vous repasserez...)

Je suis d'accord, pour la rédaction de la grammaire c'est vraiment sympa. Mais pour quelqu'un qui ne connaît pas du tout boost et qui n'a jamais touché à l'analyse syntaxique en général, ce n'est pas si évident et on a vite faite de faire partir l'analyseur en boucle infinie (je l'ai fait quelques fois pendant mon dev :mrgreen:, heureusement je savais ou chercher l'erreur).

Citation:

Envoyé par Goten

Bon par contre ça a des inconvénients, le bloat

Je ne trouve pas grand chose sur le sujet sur le net, ni sur les DSEL en général. Aurais tu quelques sources intéressantes ?

Citation:

Envoyé par Goten

(c'est un faux problème, les gens ont qu'a utilisé des vraies compilo et des PCH)

Je n'avais pas pensé aux PCH, c'est une bonne idée aussi !

@mister3957 : Je mettrais le code sur GitHub dès ce soir, comme ça tu n'auras pas besoin d'attendre la rédaction du tuto pour tester.
04/01/2011, 13h20
poukill

Intéressant ce thread ! ;)

Citation:

Envoyé par mister3957

Pour être plus précis, je travail sur un projet cartographique et je dois gérer les zooms de l'application.

Pour faire le curieux ? Quel genre exactement ? Tu connais QuantumGIS ?

Citation:

Envoyé par Goten

Le vraie avantage, c'est le fait que ça soit un DSEL. Avec en vrac une syntaxe (très) proche de l'EBNF (c'est pour ça que l'histoire du "faut 40 ans pour le maitriser" vous repasserez...), le fait que tout soit déroulé à la compilation et les perfs induites. (suffit de voir comment karma surpasse atoi).

Bon par contre ça a des inconvénients, le bloat (si quand même un minimum), la vitesse de compilation (c'est un faux problème, les gens ont qu'a utilisé des vraies compilo et des PCH)

Merci Goten, ça faisait un bout de temps que j'avais pas vu autant d'acronymes que je ne connaissais pas dans le forum C++ ! Rien compris ! :aie:

@jb : ça m'intéresse aussi, mais moi je peux attendre le tuto ! ;)
04/01/2011, 13h45
mister3957

Citation:

Envoyé par jblecanard

Mais pour quelqu'un qui ne connaît pas du tout boost et qui n'a jamais touché à l'analyse syntaxique en général, ce n'est pas si évident

Lorsque j'ai à choisir, je préfère accorder plus d'importance à ce qu'a besoin le projet en essayant de rester au maximum "libre", qu'aux capacités/limites de "quelqu'un" sachant qu'une partie de son travail est de s'adapter aux différentes contraintes techniques. Donc ça ne me dérange pas ;)

Citation:

Envoyé par jblecanard

@mister3957 : Je mettrais le code sur GitHub dès ce soir, comme ça tu n'auras pas besoin d'attendre la rédaction du tuto pour tester.

Merci infiniment :)

Citation:

Envoyé par jblecanard

Pour faire le curieux ? Quel genre exactement ? Tu connais QuantumGIS ?

Non je ne connais pas mais étant donné que ça fait parti de l'OSGeo, je ne vais pas tarder à mettre les pieds dedans ;)
J'essaye de traiter le VRP (Vehicle Routing Problem) sous diverses contraintes en essayant d'être le plus performant et flexible possible. C'est sympa, divertissant et passionnant à étudier, développer ;)
04/01/2011, 15h31
Jean-Marc.Bourguet

Citation:

Envoyé par jblecanard

Que conseilles-tu d'utiliser alors dans ce cas ?

Un ecrire un a la main, c'est pas complique quand meme:
http://www.developpez.net/forums/d38...s/#post2356000
04/01/2011, 16h19
jblecanard

Citation:

Envoyé par Jean-Marc.Bourguet

Un ecrire un a la main, c'est pas complique quand meme:
http://www.developpez.net/forums/d38...s/#post2356000

Joli ! Gères-tu la priorité entre les opérateurs ? Mais si tu veux complexifier (ne serais-ce qu'un tout petit peu) ta grammaire, ça devient vite emmerdant à maintenir.
04/01/2011, 16h29
mister3957

Citation:

Envoyé par jblecanard

Mais si tu veux complexifier (ne serais-ce qu'un tout petit peu) ta grammaire, ça devient vite emmerdant à maintenir.

Exactement !
04/01/2011, 17h48
Jean-Marc.Bourguet

Citation:

Envoyé par jblecanard

Joli ! Gères-tu la priorité entre les opérateurs ?

Ce parseur la est de la descente recursive: il y a en gros une fonction par non terminal dans la grammaire et on appelle la fonction qui va bien ou ca va bien. C'est le genre de code qui est genere par certains types de generateurs. (Avec ces generateurs, je me retrouve souvent en fait a penser au code final que je veux puis a essayer de l'exprimer dans la syntaxe du generateur).

Citation:

Mais si tu veux complexifier (ne serais-ce qu'un tout petit peu) ta grammaire, ça devient vite emmerdant à maintenir.

Oui et non. Si la grammaire change tout les jours et est suffisamment sous contrôle pour que ses changements respectent les contraintes du générateur, je suis d'accord. Sinon, le travail d'adaptation aux contraintes du générateur est tout aussi emmerdant -- et avec certains générateurs, beaucoup moins intuitif.

Sinon, j'ai de l'experience en la matiere avec des parseurs ecrits a la main et des parseurs utilisant des generateurs (j'ai meme ecrit des generateurs). A la fois pour des langages normalises, et pour des formats de description de fichiers divers.

Pour ces derniers (ou en fait la mode de nos jours serait d'utiliser du XML, mais ils ont un historique predatant XML -- XML decrit directement l'AST, si on fait un langage on va essayer d'etre plus lisible), les generateurs sont interessants. Parce que le format est sous notre controle (et donc qu'on peut choisir de ne pas et que l'adequation de la grammaire avec le generateur est donc garantie. C'est ce que j'apellais la complexite moyenne.

Pour les langages, les generateurs sont plutot une gene: ils facilitent un peu les 80% du boulot le plus facile mais rende encore plus penible les 20% restant (les parties du langage non LALR et sortir des messages d'erreur d'une qualite convenable, en particulier quand on veut un parseur unique pour traiter -- les generateurs GLR sont une solution pour le premier point, mais je n'ai aucune indication qu'il y ait une solution convenable avec des generateurs pour le second). C'est pas un hasard si gcc a laisser tomber les generateurs pour le C et le C++ et n'en a jamais utilise de generateur pour Ada (il me semble que c'est le cas de clang aussi).

Pour quelque chose de simple comme des expressions, en fait n'importe quoi qui est familier est préférable a quelque chose de pas familier. Mais un programmeur pas familier avec les techniques pour les écrire a la main a un trou dans sa formation.
04/01/2011, 21h33
jblecanard

Citation:

Envoyé par Jean-Marc.Bourguet

Pour quelque chose de simple comme des expressions, en fait n'importe quoi qui est familier est préférable a quelque chose de pas familier. Mais un programmeur pas familier avec les techniques pour les écrire a la main a un trou dans sa formation.

J'admire ton expertise en la matière, mais je ne crois pas que savoir écrire proprement un parseur, même simple, soit à classer dans les techniques de base. Il y a quand même pas mal de notions formelles que beaucoup de programmeurs ne connaissent pas. J'ai pas mal étudié ça en cours et je ne m'en rapelle clairement pas assez pour écrire sereinement un parseur propre. Il faudrait que je réétudie les techniques.

Sinon, si on applique ton avis sur l'interpréteur que suis en train de fignoler, je pense que j'arrive pile dans la marge ou ça me fait bien plaisir d'avoir un générateur et où je n'ai pas besoin de me battre avec ses limites.
05/01/2011, 02h15
jblecanard

Messieurs, voici enfin mon interpréteur, j'espère qu'il va vous plaire. Vous le trouverez sur GitHub.

@Jean-Marc : Je ne sais pas si tu as déjà essayé spirit entre autres générateurs, mais je l'ai trouvé bien plus simple à utiliser (de très loin) que les 2 ou 3 que j'ai rencontrés par le passé.

Plutôt que d'aller directement lire le code, qui risque d'être imbitable au premier abord, je vous invite à lire le Main.cpp qui contient tous les exemples nécessaires à sa compréhension et à son utilisation. Ne vous y fiez pas, il y a quelques subtilités de bon aloi :mrgreen:. Le code de l'outil en lui même fait 200 lignes à tout casser, tout compris.
05/01/2011, 12h39
Goten

Citation:

Envoyé par jblecanard

Messieurs, voici enfin mon interpréteur, j'espère qu'il va vous plaire. Vous le trouverez sur GitHub.

@Jean-Marc : Je ne sais pas si tu as déjà essayé spirit entre autres générateurs, mais je l'ai trouvé bien plus simple à utiliser (de très loin) que les 2 ou 3 que j'ai rencontrés par le passé.

Plutôt que d'aller directement lire le code, qui risque d'être imbitable au premier abord, je vous invite à lire le Main.cpp qui contient tous les exemples nécessaires à sa compréhension et à son utilisation. Ne vous y fiez pas, il y a quelques subtilités de bon aloi :mrgreen:. Le code de l'outil en lui même fait 200 lignes à tout casser, tout compris.

T'es allergique à boost.function?
05/01/2011, 13h17
jblecanard

Citation:

Envoyé par Goten

T'es allergique à boost.function?

Pas du tout, pourquoi donc ? Je n'ai pas ressenti de besoin mais si ça peut me faire gagner encore en poids et en flexibilité, je vais regarder. Je suis encore débutant avec Boost, j'ai codé ça en guise d'exercice...

Edit : En effet, ça peut économiser un héritage un peu lourdingue. Pour la prochain "release" donc ;)
Edit 2 :
- Pour la suite de l'évolution de l'outil, c'est ici.
- Pour la suite de l'évolution de l'éventuel tuto, c'est là.
05/01/2011, 21h54
Jean-Marc.Bourguet

Citation:

Envoyé par jblecanard

J'admire ton expertise en la matière, mais je ne
crois pas que savoir écrire proprement un parseur, même simple, soit à
classer dans les techniques de base. Il y a quand même pas mal de notions
formelles que beaucoup de programmeurs ne connaissent pas. J'ai pas mal
étudié ça en cours et je ne m'en rapelle clairement pas assez pour écrire
sereinement un parseur propre. Il faudrait que je réétudie les techniques.

Je diagnostique un cours trop basé sur la théorie accompagné de pas assez
de pratique. Je ne pense pas être expert en la matière (j'ai trop de trous
dans mes connaissances pour l'être, en commencant par tout ce qui s'est
fait les 10 dernières années, mais même il y a 10 ans j'étais expérimenté
mais pas expert) et la technique que j'ai utilisée est loin d'être une
technique d'expert. Si j'avais à donner un cours sur les compilateurs, je
l'introduirais plutôt avec une phrase du genre "si vous ne devez retenir
qu'une chose, c'est cette technique".

Citation:

Sinon, si on applique ton avis sur l'interpréteur que suis en train
de fignoler, je pense que j'arrive pile dans la marge ou ça me fait bien
plaisir d'avoir un générateur et où je n'ai pas besoin de me battre avec
ses limites.

C'est pas mon avis. Plus loin tu déclares:

Citation:

Envoyé par jblecanard

Ne vous y fiez pas, il y a quelques subtilités de
bon aloi :mrgreen:. Le code de l'outil en lui même fait 200 lignes à tout
casser, tout compris.

Pour rappel, le code que je donnais fait 150 lignes. Si on lui enlève le
traitement particulier de sin et cos et ajoute le traitement de
l'exponentiation et des fonctions en général, on ne va pas être très loin
de 200 lignes (mais plutôt de l'autre côté, je suis d'accord) de C pur,
sans subtilités. Même si on double pour avoir une encapsulation correcte
en C++, je ne suis pas convaincu du tout que ça vaille la peine de tirer
tout Spirit. Je suis certain que ça ne vaut pas la peine d'apprendre
Spirit pour ça.

Citation:

Plutôt que d'aller directement lire le code, qui risque d'être
imbitable au premier abord,

Moi j'invite à lire mon code, j'espère qu'il n'est pas imbitable, même non
documenté, même sans avoir eu un exposé sur la technique utilisée ;)

Citation:

@Jean-Marc : Je ne sais pas si tu as déjà essayé spirit entre autres
générateurs, mais je l'ai trouvé bien plus simple à utiliser (de très loin)
que les 2 ou 3 que j'ai rencontrés par le passé.

Je n'ai rien contre les générateurs (je n'en aurais pas écrit sinon). Je
pense simplement qu'ils sont trop souvent utilisés en dehors de leur zone
de pertinence parce qu'on ne présente pas assez les alternatives. En
passant, un avantage des générateurs que je n'ai pas donné plus haut est
que quand ils acceptent la grammaire de référence sans modification, ils
offrent une garantie très forte de ne pas accepter un autre langage que
celui de la grammaire.

J'ai déjà regardé Spirit et je vois plus ou moins comment il fonctionne
(c'est à dire que je vois très bien comment je ferais fonctionner qqch de
semblable, mais comme il y a un certain nombre d'alternatives possibles, je
ne sais pas les quelles ont été choisies). Je ne l'ai jamais utilisé mais il fait partie des options que j'explorerai plus en détail si le besoin s'en fait sentir.
06/01/2011, 10h23
jblecanard

Quand je parle de code imbitable, c'est pour qui ne connaît rien de boost ;)
Quand je parle de petite subtilités, c'est sur mon choix de l'interface C++ ;) par sur le code derrière, qui est somme toute assez simple pour un utilisateur de boost expérimenté.

Je comprend ton avis : le coût d'apprentissage de Spirit + le codage revient au même (ou coûte plus cher) que le faire à la main. On est pas à centaine de lignes près d'ailleurs si tu ne tires sur rien.

Moi je me place dans un autre contexte : je pars du principe que je connais Spirit et que je n'ai que le coût de dev. Parce que l'apprentissage pourra me resservir plus tard, et c'est là que le temps sera gagné. Dans un contexte professionnel ou tu es serré sur le temps, mon point de vue ne marche pas. Mais ce n'est pas mon cas ici, et mon code pourra resservir à d'autres, un tirage sur boost (headers only) n'étant pas très cher.
06/01/2011, 11h10
Jean-Marc.Bourguet

Citation:

Je comprend ton avis : le coût d'apprentissage de Spirit + le codage revient au même (ou coûte plus cher) que le faire à la main. On est pas à centaine de lignes près d'ailleurs si tu ne tires sur rien.

Je parle meme hors du cout d'apprentissage. Si j'ai le choix entre ecrire 300 lignes de code simple ou ecrire 200 lignes et ajouter une dependance, je ne vais pas ajouter de dependance, meme si je sais deja me servir de la dependance; je ne l'utiliserais probablement pas meme si la dependance est deja utilisee dans un autre contexte dans le projet.

Il n'y a que trois raisons qui me feraient utiliser autre chose qu'un parseur ecrit a la main pour un evaluateur d'expression comme le tien:
- je prevois de le faire evoluer vers un langage plus complet;
- c'est un exercice de style ou d'apprentissage d'un generateur ou d'une lib du genre Spirit;
- c'est impose par ma hierarchie en depit de mon avis contraire.

Citation:

Moi je me place dans un autre contexte : je pars du principe que je connais Spirit et que je n'ai que le coût de dev. Parce que l'apprentissage pourra me resservir plus tard, et c'est là que le temps sera gagné. Dans un contexte professionnel ou tu es serré sur le temps, mon point de vue ne marche pas. Mais ce n'est pas mon cas ici, et mon code pourra resservir à d'autres, un tirage sur boost (headers only) n'étant pas très cher.

Dans mon contexte professionnel, il y a les questions du genre "est-ce que ca vaut la peine de faire intervenir le departement legal pour valider l'utilisation de la lib?", "qu'est-ce qu'on fait si la lib a un bug?", "est-ce que ca vaut la peine de devoir se coordonner avec les autres equipes lors des mises a jour de la lib?", "est-ce qu'on est raisonnablement sur d'avoir la lib maintenue dans 10 ans?", "est-ce que c'est sense de demander a ceux qui vont maintenir le code -- ca fini toujours par etre d'autres personnes que ceux qui l'on développé -- de connaitre/apprendre la lib?"
06/01/2011, 11h28
jblecanard

Citation:

Envoyé par Jean-Marc.Bourguet

- c'est un exercice de style ou d'apprentissage d'un generateur ou d'une lib du genre Spirit

C'est exactement mon cas :)

Citation:

Envoyé par Jean-Marc.Bourguet

Dans mon contexte professionnel, il y a les questions du genre "est-ce que ca vaut la peine de faire intervenir le departement legal pour valider l'utilisation de la lib?", "qu'est-ce qu'on fait si la lib a un bug?", "est-ce que ca vaut la peine de devoir se coordonner avec les autres equipes lors des mises a jour de la lib?", "est-ce qu'on est raisonnablement sur d'avoir la lib maintenue dans 10 ans?", "est-ce que c'est sense de demander a ceux qui vont maintenir le code -- ca fini toujours par etre d'autres personnes que ceux qui l'on développé -- de connaitre/apprendre la lib?"

100% d'accord, chacun fait en fonction de ses contraintes. Ce n'est pas forcément compliqué si Boost est déjà dans le projet. Mon code est libre de droit, celui de ne pas l'utiliser compris :mrgreen:
06/01/2011, 12h15
Jean-Marc.Bourguet

Citation:

Envoyé par jblecanard

C'est exactement mon cas :)

C'est bien ce que j'avais compris. Je suis intervenu parce que personne ne proposait a l'OP autre chose que l'utilisation de generateur ou de lib generique, et que c'est le cas a chaque fois qu'on cause de parsing.