Discussion :

[pymouse]

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

[kromartien]

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.

[pymouse]

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

[Bayard]

Python est un langage idéal pour cela.
Je l'ai déjà fait.

[kromartien]

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

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 coup

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

[gege2061]

Bonjour,

Le Langage C suffirais t'il ?

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 !

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

car il possède des opérateurs dédiés efficaces

Pour le parsing T'as de la doc la dessus ?

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

[gege2061]

sachant que le support des expressions régulières est natif dans perl, ça me semble plus facile de traiter des chaînes avec.

Ah ok, sauf que le parsing à coup d'expressions régulières c'est soit infaisable soit illisible

[kromartien]

Illisible je veux bien vous croire , mais je ne vois pas comment ça pourrait être infaisable.

[pymouse]

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

[granquet]

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

[gege2061]

Illisible je veux bien vous croire , mais je ne vois pas comment ça pourrait être infaisable.

Par exemple un parser XML :

Code xml :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<ui>
  <menubar>
    <menu name="Fichier">
      <menu name="Nouveau">
        <menuitem name="Source" />
        <menuitem name="En tete" />
      </menu>
      <menuitem name="Ouvrir" />
    </menu>
  </menubar>
  <toolbar>
    <menuitem name="Nouveau" />
  </toolbar>
</ui>

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.

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

[granquet]

si c'est du xml, y'as libxml2 qui fait tres bien son boulot

[pymouse]

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

[Jean-Marc.Bourguet]

J'ai juste un certain nombre de fichier.h

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

[Franck.H]

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

[kromartien]

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.

[Jean-Marc.Bourguet]

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.

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.

[kromartien]

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 avec

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

[Jean-Marc.Bourguet]

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)

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