Un parser entièrement à la main? Mais il est fou!

Bonjour

J'utilise actuellement dans un de mes programmes un parser que j'ai écrit entièrement à la main (le langage est assez simple, a peu près équivalent au C).
Pour l'instant j'ai l'ensemble du code sur environ 2000 lignes et je n'ai pas trop de problème.
En fait je regrette de ne pas avoir utilisé dès le début une générateur de compilateur (je savais pas que ca existait en fait :oops: )
Mon problème est que je découvre de temps en temps des petites erreurs (comptage de lignes par exemple, ou plus grave des fois).
Selon vous, est-ce que ca vaut le coup de tout refaire?
Si oui, avec quoi? (je connais (l'existence de) Lex et Yacc, enfin flex et bison je suis sous Windows)

Merci de vos conseils

Ca dépend, si ton code est stable c'est peut-être inutile de le refaire... bien que 2000 lignes de codes ça commence à faire quand même pour un parseur :roll:

Donc y'a plusieurs choses :

- La syntaxe de ton langage est elle simple ou c'est quand même pas mal compliqué ?
- Est ce que tu penses que ton langage devra évoluer ? Si oui, est ce que ton code le permet facilement ?
- Quand tu rencontre un bug, t'est il difficile de le localiser ? De le résoudre ?

Tu tu trouves que ça n'est pas viable, il faudrait en effete reprendre le code...

Lex/Yacc ou Flex/Bison, c'est pas mal... j'ai eu l'occasion de jouer un peu avec et j'ai pu faire des trucs assez sympas.

Sinon, un peu plus clean et orienté C++ tu peux allé voir du coté de boost :
http://www.boost.org/libs/spirit/index.html

Le langage est plus simple que le C, donc pas très compliqué.
C'est un langage qui n'évolue pas et en général avec un débugger je trouve l'erreur aussitôt
J'ai finalement décidé de garder le code actuel
Il me reste encore a écrire le préprocesseur (le même que C)
Merci

Citation:

---

(le langage est assez simple, a peu près équivalent au C).

---

Pourquoi ne pas prendre une grammaire EBNF pour du C et la modifier selon tes besoins ?

Citation:

---

Il me reste encore a écrire le préprocesseur (le même que C)

---

Dans ce cas-là pourquoi ne pas réutiliser une implémentation du préprocesseur C ?

Si ton code fonctionne bien tu peux en effet le conserver mais Lex/Yacc sont vraiment 2 excellent outils. Viellots mais excellents.

Le seul reproche que je leurs ferais est le non support du c++ en generation.
Du coup tu ne vois pas ton parser comme une classe mais comme des fonctions.

Ce n'est pas genant en soit pour l'integration, j'ai deja realisé des Machine Virtuelle et un langage de script avec le tout en c++ mais ca fait pas tres clean dans un programme bien structuré objet.

Il existe cependant une version MKS de lex/Yacc avec "support" c++ mais presque 400€ la licence ca fait cher pour un particulier.

Tu as une autre alternative Flexx++ et bison++

Si le premier fonctionne pas trop mal, le second :aie: mais je n'ai pas trop chercher c'est vrai :roll:

Autrement il y a Spirit de BOOST dont j'entend du bon comme du moins bon.
Il faudras que j'essai un jour.

Quel est l'objectif reel de ton projet car c'est un sujet qui m'interesse ?

Le langage que j'étudie est celui des fichiers ressource de Microsoft (extension .rc)
J'ai regardé le source de MinGW (binutils plus exactement), mais c'est vraiment trop long pour moi, je vais garder mon code qui certes ne lit pas tous les fichiers (surtout s'ils sont tordus) mais qui suffit pour une utilisation normale

Je ne connais pas le langage que tu tentes de parser, mais s'il est tiré du C il est fort possible qu'il soit plus facile de le parser correctement avec un parseur écrit à la main qu'avec un écrit avec lex et yacc. Je me souviens en particulier d'un point qui pose problème et pour lequel il faut faire des hacks si on utilise yacc, c'est la gestion des typedefs. (En C++ j'en vois d'autres, mais ils ne s'appliquent pas au C).

Un avantage d'un parseur écrit à la main, c'est qu'il est normalement plus facile de lui faire générer de bons messages d'erreur et de continuer à parser.

Ce n'est pas tout à fait sans raisons qu'ils ont réécrits les parseurs de gcc pour le C et pour le C++ à la main, alors qu'ils utilisaient bison auparavant. (Et B.S. a écrit quelque part qu'une des erreurs qu'il avait commise lors de l'écriture de CFront, c'était d'avoir écouté ceux qui lui conseillaient lex et yacc).