Version imprimable
Bonjour,
Selon vous quel serait le meilleur langage pour parser des fichier .h, pour faire un fichier .idl ?
Le Langage C suffirais t'il ? Comment bien optimiser son code ? Car avec le C je me vois contraint de faire une imbrication de if/switch case assé importante...
Ou bien peut être lex/yacc mais qui me semble un peu une usine a gaz pour ce que j'ai besoin de faire.
C++? Java? Python? ...
Si vous avez des pistes ou conseils...
Merci
le langage traditionnel de parsage de fichiers textes est le langage perl, car il possède des opérateurs dédiés efficaces, mais il est possible de le faire en C au prix d'un coût de développement plus important.
D'ailleurs lorsque j'ai besoin de faire un traitement dédié, j'utilise le C qui est le seul langage que je sais utiliser de prime abord pour l'instant, mais je suis bien certain qu'en connaissant un peu de perl, il est très facile de créer un script qui fait le travail en deux temps trois mouvement.
Je maitrise beaucoup plus le C au PERL, donc je ne sais pas si je ne vais pas mettre plus de temps a comprendre le perl que de directement développer en C, même si cela risque d'être un peu plus long (niveau codage). Ca va pas être évident tout de même :P
Python est un langage idéal pour cela.
Je l'ai déjà fait.
le perl est beaucoup plus souple que le C et surtout dédié, si vous avez le temps d'apprendre un nouveau langage ça vaut le coupCitation:
Envoyé par pymouse
@Bayard : Python peut être, mais il n'a pas vraiment la même vocation que le perl, bien qu'étant également un langage de script très souple. De plus, pymouse connait le C, et la syntaxe du langage Perl se rapproche plus de celle du C que celle du langage Python qui est complétement différente de celle du C.
Bonjour,
Sachant que tu peux tout faire avec n'importe quel langage, la question est plutôt de savoir combien de temps tu vas mettre à le faire !Citation:
Envoyé par pymouse
En C pourquoi pas si t'as envie de t'amuser / découvrir des choses, si tu veux être efficace, Perl me parait bien mieux : CPAN - Parser
Pour le parsing 8O T'as de la doc la dessus ?Citation:
Envoyé par kromartien
sachant que le support des expressions régulières est natif dans perl, ça me semble plus facile de traiter des chaînes avec. Enfin, oui, je crois bien que perl est spécialisé dans le parsing et le traitement de chaînes (sachant qu'on ne fait pas de parsing sans faire du traitement de chaîne à mon avis) .
Oui ce que je veux dire par opérateurs dédiés ce sont toutes les fonctions standards de manipulations de chaîne et le typage faible qui permet de manipuler des chaînes comme des scalaires.
Enfin c'est vrai que faire un utilitaire C dédié est peut être plus précis et plus rapide pour un traitement de fichiers en masse et à la chaîne, mais au prix d'une complexité dans le développement plus importante.
En supplément, le perl est un langage de script, donc pas de souci de gestion de la mémoire, ce qui est appréciable en manipulant des fichiers textes via des buffers de taille limitée.
Mais bon faire un programme C ça peut marcher aussi, je ne le renie pas.
Ah ok, sauf que le parsing à coup d'expressions régulières c'est soit infaisable soit illisible :(Citation:
Envoyé par kromartien
Illisible je veux bien vous croire , mais je ne vois pas comment ça pourrait être infaisable.
Les expréssions régulières ça simplifie le parsing! En C, c'est limite du caractère par caractère, pour touver un crochet/accolade ouvrant puis le fermant etc...
Je suis partie sur du PERL, rien que pour la manipulation des fichier c'est du bonheur, en une ligne je me retrouve avec un tableau de tous les fichier .h du répertoire que je souhaite.
Maintenant me reste a trouver l'algo et les bonnes expréssions régulières :aie:
pour parser ... ça depend de la complexitée des données a parser ...
mais flex/bison (pendants GNU de lex/yacc) est a mon avis la solution la plus rapide et efficace d'un point de vue purement objectif ...
maintenant si t'as juste un fichier .ini a parser ... ça fait tres usine a gaz ...
Par exemple un parser XML :Citation:
Envoyé par kromartien
C'est le style de fichier utilisé par GTK pour construire des menu et des barre d'outils (donc un cas tout à fait réel), avec les regex ça risque d'être compliqué à interpréter.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
Pour implémenter un parser il faut se baser sur un automate à état, enfin pour les cas d'école, je ne suis pas non plus un expert en parsing. Recursive descent parser
Maintenant avec Perl tu dois avoir des dizaines de modules déjà développé donc tu n'as pas à t'occuper de ça ;)
si c'est du xml, y'as libxml2 qui fait tres bien son boulot ;)
J'ai juste un certain nombre de fichier.h a parser pour en faire un .IDL :)
Perl me semble pas trop mal, flex/bison yacc etc... Trop usine a gaz...Mais certe très puissant :)
Suivant le genre de choses qui sont autorisees dans le .h et la robustesse, je crains que perl pose vite un probleme, parser complement du C n'est pas tres facile. Si tu peux imposer des contraintes ou accepter qu'il y a des fichiers qui ne sont pas traitables, certaines heuristiques sont possibles. Meme dans ce cas, j'aurais cependant tendance a partir sur quelque chose qui puisse evoluer en un parseur complet (et pour ca, pour le C le plus simple est la descente recursive; forcer la grammaire du C a etre utilisable par yacc pose quelques problemes interessants dont la resolution tient plus du hack qu'autre chose; gcc par exemple a abandonne son parseur C en bison).Citation:
Envoyé par pymouse
En C c'est tout à fait faisable et plus ou moins rapide et facile dans la mesure où tu disposes déjà de lib perso comme un objet String etc... Etant donné que tu risque de faire pas mal d'opérations sur les chaînes, surtout recherche de sous-chaînes, test de présence de certains caractères etc...
Moi j'ai un objet String très complet si jamais tu le fait en C et si tu en veux ;)
En tous cas si c'est fait en C ça implique beaucoup de mécanique de pointeur et une bonne maîtrise de la lib string.h, qui est assez bien fournie sur le sujet.
Je ne vois pas en quoi un parseur a besoin de l'entete (et pas la bibliotheque, et encore moins la lib) string.h.Citation:
Envoyé par kromartien
Et suivant ce qu'on fait, pas partiruclierement des pointeurs. Si l'objectif est de produire une representation du genre AST, oui, on va avoir de pointeurs ou d'equivalent. Mais en n'importe quel langage.
:oops: Il est possible que j'ai mal compris la question.
Un parseur sert bien à vérifier la validité d'un document xml par exemple, ou encore la validité syntaxique d'un programme C, etc toutes ces choses.
(je crois du moins)
Alors, pour lire dans les fichiers textes en C, on utilise stdio avec les fonctions fgets et autres.
Ensuite pour regarder et manipuler les chaînes de caractère, on utilise bien des const char * et des char *.
Et alors il semble normal d'utiliser string.h de la glibc.
Mais je ne vois pas où j'ai tort dans ma conception de ce qui constitue un parseur de fichiers textes.
Merci de m'indiquer plus précisément de quoi il s'agit alors.
:( car je me sens un peu largué, merci de corriger si je dis n'importe quoi.
--
Ou alors peut être qu'il est possible de n'utiliser qu'une conception algorithmique avec des pointeurs pour déterminer un modèle à respecter,
avec appel récursif (comme vous disiez plus haut) de genre de chose pour valider les balises fermantes/ouvrantes.
Mais bon utiliser les fonction de la bibliothèque string peut être utile tout de même.
En tous cas ce que vous dites semble être en contradiction avecCitation:
Envoyé par Franck.H
On divise traditionnellement la tache en deux: analyse lexicale qui consiste a retrouver les "mots" (lexeme, token) et l'analyse gramaticale qui consiste a retrouver la structure. Un parseur fait la deuxieme phase et ne manipule generalement pas des caracteres. Meme pour la premiere, le contenu de string.h est d'utilite tres limitee (les fonctions de ctype.h sont plus utiles meme si les techniques d'implementation habituelles a base de FSM ne les utilisent pas).Citation:
Envoyé par kromartien
Citation:
Envoyé par Jean-Marc.Bourguet
Pardon, pourriez vous éviter d'utiliser des acronymes peu usuels sans en donner le sens dans les premières ligne de vos explications, car je ne comprends pas du tout ce que vous voulez dire dans ces conditions, et ce n'est pas faute d'essayer.Citation:
Envoyé par Jean-Marc.Bourguet
FSM: Finite State Machine (machine a etat finit ~= automate) : http://en.wikipedia.org/wiki/Finite_state_machine
AST: Abstract Syntax Tree : http://en.wikipedia.org/wiki/Abstract_syntax_tree
je te rassure, j'ai eu des dizaines d'heures de cours dessus ... et j'ai pas tout compris ... alors comme ça a froid ... j'imagine bien ce que ça donne ;)
C'est difficile de répondre a quelqu'un qui commente sur le domaine en supposant qu'il va considérer le vocabulaire de ce domaine comme "peu usuel".Citation:
Envoyé par kromartien
AST: abstract syntax tree. Les parse tree, c'est les arbres, qu'on dessinait en grammaire quand j'etais gosse, decrivant la structure grammaticale des phrases. Un AST, c'est une version simplifiee du parse tree ne comportant que ce qui est "interessant". C'est une des structures de donnee generees par les parseurs quand ils ne font pas produisent pas directement le produit fini.
FSM: Finite State Machine. Machine d'etats finie, automate. C'est entre autres une technique d'implementation des expressions rationnelles.
c'est un peu une usine a gaze, mais je ne peux que conseiller codeworker :-)
http://codeworker.free.fr/
allez y faire un tour, vraiment tres puissant.
y'a même un tuto qui traîne sur developpez (c'est comme ca que j'ai appris).