Evaluation d'une expression numérique

**mister3957** · 02/01/2011, 19h42

Bonjour à tous,

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

Code :

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

(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

**Davidbrcz** · 02/01/2011, 20h12

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.

**bretus** · 03/01/2011, 01h05

Bonsoir,

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

Tu arriveras à interpréter ceci :

Code :

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

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.

**Joel F** · 03/01/2011, 08h17

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 ...

**jblecanard** · 03/01/2011, 11h22

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 !

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 !

**bretus** · 03/01/2011, 13h15

Bonjour,

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

**jblecanard** · 03/01/2011, 13h52

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.

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.

**Joel F** · 03/01/2011, 17h28

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

mais passons ...

**jblecanard** · 03/01/2011, 17h37

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.

**Jean-Marc.Bourguet** · 03/01/2011, 18h41

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.

**Joel F** · 03/01/2011, 19h14

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

**jblecanard** · 04/01/2011, 11h12

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.

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.

**mister3957** · 04/01/2011, 12h03

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

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

**Goten** · 04/01/2011, 12h09

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)

**jblecanard** · 04/01/2011, 12h48

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

, heureusement je savais ou chercher l'erreur).

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 ?

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.

**poukill** · 04/01/2011, 13h20

Intéressant ce thread !

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 ?

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 !

@jb : ça m'intéresse aussi, mais moi je peux attendre le tuto !

**mister3957** · 04/01/2011, 13h45

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

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

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

**Jean-Marc.Bourguet** · 04/01/2011, 15h31

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

**jblecanard** · 04/01/2011, 16h19

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.