J'ai trouvé un exemple de source pour parser le code QB sur programmerheaven.
On pourrait peut-être s'en inspirer, non?
Le source s'appelle mariabasic pour ceux qui veulent aller voir.
Je n'ai pas encore regardé de très près, mais il a l'air de fonctionner, il faudrait voir pour modifier la sortie, mais bon, c'est pas le plus gros ni le plus difficile.
Cette source est dans la section C++, mais n'utilise pas de classes, il serait donc peut-être améliorable.
Je vais essayer de regarder pendant la semaine, là je suis censé bosser
J'essayerais de poster plus d'infos a ce sujet ce WE.

BONNNNNNNNNNNNNJOUR !

Et oui, je reviens un peu ! Désolé de vous avoir un peu abandonné ces derniers temps, mais c'est pas toujours facile de tout concilier ^^

J'ai pas énormement réflechis sur le projet (j'avoue, honte à moi !), mais j'ai pris le temps de regarder un peu la source que tu nous as dégoté...

Utilisez un parser existant est une bonne idée. A condition que le code source soit clair, ce qui, il faut le dire, n'est pas le cas de celui ! Peu de commentaire, tout en un seul fichier, bref, on perdrait énormément de temps à essayer de comprendre le code. Je crois que faire notre propre parser irai plus vite

Bon, c'est pas parce que j'émets une critique négative qu'il ne faut pas utiliser un parser déjà existant. J'avais écris sur le wiki la possibilité d'utiliser les outils GNU flex et yacc. Quelqu'uns les as-t-il déjà utilisés ?

J'ai vu ça l'autre jour oui. J'ai fais quelques essais avec ces outils sur un langage c-like.
Le plus dur reste a faire la grammaire en fait. Pour le lex, il suffit juste de faire la liste des mots clefs.
Cela dis, je pense qu'il serait nettement plus facile de le faire avec flex et yacc que de tout programmer à la main.

Je doit avouer que je n'ai pas non plus pris le temps d'étudier le source que j'ai trouvé, pas plus que je n'ai essayé flex et yacc...
J'avait posté cette source avant de m'apercevoir que tu avait écrit quelque chose sur le wiki, sinon, je pense que je me serait abstenu.

Pour ce qui est du parser, il va falloir définir le format des données en sortie, pour qu'elles soient compréhensibles par le traducteur.
A votre avis, il vaut mieux déterminer ce format avant de commencer, ou après avoir fait les principales routines du parser (je pense qu'il serait préférable de s'en occuper avant)?
Je pense qu'on pourrait utiliser le format xml, qui est relativement simple à mettre en oeuvre, libre et surtout déja existant (inutile de réinventer la roue, non?), ou alors utiliser des données binaires, mais l'intérêt de passer par le xml serait d'avoir des classes 100% indépendantes les unes des autres et faciliterait le débogage (inutile d'utiliser un éditeur héxadécimal).

Edité par Freem ( 17/04/2007 18:44:54 )

Les classes peuvent être 100% indépendante avec un codage binaire, cela n'a rien à voir avec XML.

Par contre, XML augmente fortement la portabilité, en s'asbtrayant de la représentation des données véhiculé par un document. Par exemple, un entier, c'est 16, 32 ou 64 bits ? Dans quel ordre ? Little endian ou big endian ? Ce dont souffre le codage binaire !

Le gros avantage est, comme dis Freem, pour le debogage : pas besoin de se casser la tête pour interpréter les données : il suffit de lire !

Mais avant de définir un format d'échange, entre parser et traducteur, il faut impérativement réfléchir sur les données qu'il est nécessaire d'échanger...

Bonjour à tous,

Le xml est portable mais lent a parser. Si on utilise des structures binaires, on peut traiter plus de données plus rapidement. Et même si le processeur est big ou little endian les changements dans le code devraient être minimes si on veut garder une seule des normes.

Pour la portabilité du binaire, je ne pense pas que ce soit bien grave car je ne pense pas que l'utilisateur va compiler une partie de son code sur x86, mettre tout sur clef usb, et utiliser un powerPC pour terminer.

Le gros problème c'est que les deux formats ont des atouts ou des points faibles. Il faudra de toute facon choisir. Le top du top serait (a mon humble avis) de sortir du xml uniquement pour le debug, et du binaire pour l'utilisation finale.

kod128=> Je n'aurai pas dis mieux: xml au débug, binaire en realease, nickel

Edité par Freem ( 25/04/2007 23:25:03 )

ca marche pour moi également.

Bijour bijour !

Alors, j'ai réflichis un peu au projet, notemment à la partie parser ^^. Je fais quelques tests avec flex et bison pour voir comment cela marche. Premier constat : c'est tres pratique ! C'est relativement simple à implémenter, et cela marche sans souci pour l'instant.

Je vous rassure, je n'ai rien fait au niveau parser, j'ai juste regarder les outils que nous allons très certainement utiliser

Deuxième constat, le schéma parser d'un coté, et traducteur/interpréteur de l'autre est un peu fantaisiste. Si le parser peut détecter les erreurs de syntaxe, quand est-il des variables redéclarées, des fonctions redéclarées, des opérations incompatibles (entier + chaine de caratères, par exemple). Bref, je pense qu'il faut intercaler un vérificateur "sémentique", qui vérifie tout cela.

Une petite note vis à vis des langages utilisés : flex et bisons impose une partie en C. Je pense aussi que le vérificateur sémentique sera beaucoup plus facile à coder en C++ qu'en C. D'une part, parce que je pense qu'une approche objet nous aidera beaucoup, d'autre part, la librairie standard C++ offre des templates qui pourront nous être très utile. Par exemple, pour associer un nom (par exemple, une variable), à une structure (qui décrit la variable), le template maps pourrait être d'une grande aide.

Si on suit cette approche, il faudra alors faire ue interface C/C++, mais cela ne relève pas d'une grande difficulté...

Qu'en pensez vous

Edité par Francesco ( 13/06/2007 22:17:04 )

l'interface C/C++ n'est absolument pas un problème.
Le truc un peu plus chiant concerne la portabilité de flex, je sais pas si ca marche sous win, je regarderai

avec cygwin, ca passe sans problème ^^

[edit]
Chose qui n'a rien à voir, mais je pense aussi que nous devrions choisir un IDE. Personnellement, je connais Visual Studio C++, DevCpp et Code::Block.

A choisir, je pense que Code::Block est le mieux, car :
1) Dispo sous Windows & Linux
2) Possibilité de faire un makefile manuellement, et donc permettre une compilation facile en dehor de l'environnement, pour les partisants de vi, emacs et compagnie ^^
[/edit]

Edité par Francesco ( 13/06/2007 22:33:25 )