Discussion :

[JolyLoic]

Visual C++ gère aussi les regex depuis plusieurs années. Globalement, ce compilateur à tendance à être assez lent pour le support du langage, mais rapide pour le support des bibliothèques.

[ptyxs]

Oui, enfin à l'heure actuelle les regex, ce n'est plus une affaire de bibliothèque mais une partie intégrante du langage. Même si certains compilateurs tardent encore un peu à intégrer cet aspect de la nouvelle norme C++11, c'est en cours, et cela ne devrait plus guère tarder, sachant que pour l'instant Clang dame le pion aux autres compilateurs pour cet aspect des choses.

[JolyLoic]

Oui, enfin à l'heure actuelle les regex, ce n'est plus une affaire de bibliothèque mais une partie intégrante du langage. Même si certains compilateurs tardent encore un peu à intégrer cet aspect de la nouvelle norme C++11, c'est en cours, et cela ne devrait plus guère tarder, sachant que pour l'instant Clang dame le pion aux autres compilateurs pour cet aspect des choses.

Je parlais de la gestion des regex en tant qu'éléments de la bibliothèque standard. Je ne sais pas trop ce que tu appelles partie intégrante du langage, mais les regex restent et resteront une affaire de la biblitohèque standard. Elle ne demandent aucune modification au "core language" lui-même.

Les regex ont été introduites dans TR1 (publié en 2007 officiellement, bien que n'étant pas un standard en tant que tel). Visual C++ les as supportées à partir de visual C++2008 SP1. Elles ont ensuite été confirmées en C++11 (et basculées de std::tr1:: vers std:: ), et visual C++ les a immédiatement supportées.

Et donc Clang ne dame le pion à personne pour cet aspect (je ne dis pas qu'il n'est pas bon, loin de là, c'est juste que je n'aime pas entendre encensé un compilateur sur les aspects où il n'a rien de remarquable, et que ce soient Clang ou gcc, aucun des deux n'est particulièrement remarquable sur les aspects support de la bibliothèque standard, ce qui est d'autant plus surprenant que ce sont généralement des aspects simples à intégrer... ).

[Klaim]

Vous êtes sûrs que c’est une bonne idée de partir sur les regex ?

Je pense pareil: les regex sont notablement connu pour etre une tres mauvaise idee pour parser tout ce qui est language ou turing complete...

[JolyLoic]

Je pense pareil: les regex sont notablement connu pour etre une tres mauvaise idee pour parser tout ce qui est language ou turing complete...

Si le but était effectivement d'analyser du code C ou C++ quelconque, les regex ne suffiraient effectivement pas (et faire un parseur pour du C++ reste une tâche non triviale).

Mais là, il semblerait que le but soit de reconnaitre des motifs dans du code spécifique écrit d'une manière bien précise. Dans ce cadre, les regex me semblent appropriées.

[germinolegrand]

Un conseil, pour les regex, à moins d'être maso, il est plus que très recommandé d'utiliser les raw string (http://cpp.developpez.com/redaction/...s/cpp11/#LIV-C).

[jblecanard]

Hello guys

Si vous voulez analyser du code source C++, le mieux est quand même d'utiliser l'api C++ de LLVM/Clang. Vous aurez un véritable AST C++ analysable sur tous les aspects voulus.

C'est un peu overkill au vu du sujet de base car il y a un coût d'apprentissage, mais la solution une fois mise en place est à mon avis très simple.

[Klaim]

Si le but était effectivement d'analyser du code C ou C++ quelconque, les regex ne suffiraient effectivement pas (et faire un parseur pour du C++ reste une tâche non triviale).

Mais là, il semblerait que le but soit de reconnaitre des motifs dans du code spécifique écrit d'une manière bien précise. Dans ce cadre, les regex me semblent appropriées.

Par experience, je suis mefiant du cas ou on veut chercher des motifs dans du code. Generalement il est impossible definir ces motifs correctement simplement parceque si il sagit de semantique du langage, il ne sagit plus de motifs. Ici on parle de noms de variables, ce qui m'apparait just suffisamment complexe pour que les regex soient un piege (qui ne se voit qu'apres avoir passe trop de temps ici).

(une legere note humoristique plus ou moins a ce sujet, voir la reponse la: http://stackoverflow.com/questions/1...contained-tags )

[JolyLoic]

Disons que c'était juste la phrase "toujours à gauche de la fonction "load_bitmap"." qui me laisse penser qu'on est peut-être dans un cas assez cadré pour que ça passe. Et la différence de temps entre les deux implémentation mérite peut-être de le tenter.

Ce qui est clair, c'est que je ne ferais ça que pour du code "local", pas forcément du code livré à un client ayant pour but d'être utilisé de longues années...

[Dinoosaure]

J'aurais plutôt conseiller Flex(++) et Bison(++) qui sont les outils les plus puissants que je connaisse dans le domaine de l'analyse lexicale (automate à état fini, regex) et syntaxique (analyse LR ou plutôt LALR) - sinon, il y a l'OCaml avec ocamllex et menhir, encore plus puissant mais bon le choix a déjà été fait.

Après, tout ceci semble un peu bourrin pour la petite problématique que tu veux faire. À savoir si tu veux faire ça proprement (cf. les outils plus hauts) ou de façon tricky. Sinon, la documentation est très bien faite sur ces deux outils qui sont largement répandus. et ça m'étonnerait pas de voir déjà sur internet les fichiers correspondant à un lexer/parser C et C++ (j'ai bien trouvé PHP).

[berenm]

Hello guys

Si vous voulez analyser du code source C++, le mieux est quand même d'utiliser l'api C++ de LLVM/Clang. Vous aurez un véritable AST C++ analysable sur tous les aspects voulus.

C'est un peu overkill au vu du sujet de base car il y a un coût d'apprentissage, mais la solution une fois mise en place est à mon avis très simple.

Je pense aussi que c'est 100x plus simple. Même s'il y a un coût ça sera toujours moindre que d'essayer de faire des regex ou d'apprendre la syntaxe moisie de Bison/Flex.

Et les fonctions de parsing/ast/compilation de clang sont disponibles avec des bindings python en plus de l'API C et C++.