T'as deja regardé le code que te sort Yacc et flex ?

Franchement c'est illisible, impossible a modifier, plein de variables obscures, enfin bref : c'est moche quoi
En plus pour du basic, il suffit de séparer les token en fonction des espaces... c'est vraiment ... basique

Sinon pour visual studio :

Projet options
Propriétés de configuration Événements de génération et la que voit on ?
- option "Événement avant génération"
- option "Événement après génération"
D'ailleurs j'ai deja utilisé ces options pour travailler avec flex et yacc.

Voila pour Visual Studio. Je l'utilise presque au quotidien donc je le connais a peut près bien

Bon, pour VIsual Studio, on parlait de la même chose ^^. Il y a même une étape avant linkage.

Pour Yacc et flex, si tu t'amuse à lire le code généré, alors là oui, c'est obscure ! Normalement, il n'y a pas besoin. Pour modifier les fiichiers générés, ce sont les fichiers de bases .l et .y qu'il faut modifier !!

Et je pense que les fichiers .l et .y sont plus clair qu'un long code source... C'était ça que je voulais dire ^^

D'un autre côté, on avait dit (enfin, toi, en fait ) qu'on l'on ferait peut être les deux... avec et sans.
J'ai jeté un petit coups d'oeil à la doc que tu m'a passée, mais je n'ai pas trouvé ca très pratique à utiliser, surtout que comme l'à dit kod128, il suffit de traiter les lignes de code en fonction des espaces, sauf pour l'intérieur des chaînes ou il ne faut pas traiter les tokens à chaque espace...
Je pense que ca pourrait être plus interressant de créer le paser par nous même, puisque le but de ce projet reste d'apprendre. Mais on peut tout aussi bien apprendre à utiliser lex et yacc
Je propose un vote, ce serait plus simple.

Ok, comme vous voulez. Mais juste pour test, essayer de créer une calculette avec et sans yacc et lex.

A vous de voir la différence. Même si elle n'apparait pas, elle est présente ! Nous pouvons toujours faire les deux, cela n'empeche pas. Comme le repellait Freem, on est là pour apprendre !

L'interet d'utiliser yacc et lex, c'est aussi apprendre à ne pas toujours réinventer la roue.

Donc, comme vous l'aurez compris, je suis plutot partant pour utiliser Flex et Bison. D'autres sont pour la réalisation d'un parser à partir de 0.

On peut donc réaliser les deux parties en parallèles. Cela peut toujours être utile. Moi, je suis pour ^^

Ba après faut voire un peut...

C'est vrai que flex et yacc sont assez pratique pour faire des parsers rapidement. Mais il est possible de faire les deux (si on devais choisir un seul, autant prendre flex/yacc => solution clef en main). Toute facon la partie "lexture et transformation" du code de l'utilisateur n'est que la partie visible de l'iceberg.

J'ai deja utilisé flex et yacc mais je dis que c'est assez long a maitriser quand même . L'avantage est l'utilisation de regex et la forme sous laquelle on met la grammaire mais il faut aussi bien étudier a situation : il ne faut pas s'engager sur une fausse piste.

Je suis pour aussi ^^

Il faut effectivement réflechir avant d'agir ! Sinon, attention à la casse ^^. Nous ne sommes pas contraint par le temps, donc prenons le temps de réfléchir, plutot d'arriver au milieu du projet et devoir recommencer à cause d'un oubli.

Et pour savoir quoi faire, au niveau du lexer/parser, il faut savoir qu'est-ce que l'on doit obtenir ! C'est pour cela que, pour l'instant, je suis en train d'essayer de définir la grammaire XML pour le fichier intermédiaire dont nous avions parler i ly a quelque temps déjà.

Il s'agira d'une ébauche de grammaire, aucunement définitive et entièrement soumise à vos remarques et suggestion ^^