Discussion :

[maxim_um]

Salut,

Je cherche le meilleur parseur d'arguments de la ligne de commande, s'il existe, avant d'être obligé de m'en farcir un. Alors si vous en connaissez qui sont codés proprement, qui sont puissants et surtout intuitifs, merci d'en faire part.

Une rapide recherche m'oriente vers «Boost [program_options]», TCLAP, AnyOption. Je ne connais pas spécialement ces derniers, et comme vous le savez, la qualité d'une Lib se mesure à son usage, votre opinion est ainsi la bienvenue.

Merci.

[Luc Hermitte]

Pour moi, pour qu'ils méritent d'être considérés, ils doivent permettre d'attacher des variables C++ aux options sans devoir faire des recherches pour savoir si tel ou tel truc a bien été positionné. (j'ai été perverti par le package long-option de perl)

En plus de boost.program_option, je rajouterai ainsi argstream, plus légère.

[maxim_um]

Salut Luc Hermitte,

Je prends note pour «argstream» et à première vue, en effet ça a l'air léger.
En ce qui concerne ta remarque, je te rejoins totalement. Pour ma part, j'ajouterais que l'analyseur doit être en mesure de faire le rapprochement entre les valeurs passées en paramètre et le type des variables attendues, le cas échéant, opérer les conversions nécessaires.
Si tu as d'autres suggestions de parseurs tout faits ou de fonctionnalités pour un parseur idéal, n'hésite pas.

Je te remercie pour ton intervention.

[atm0sfe4r]

Salut,

Je te conseille Boost : il est assez complet et très performant.

Petit tuto dispo ici :
tutorial

[Luc Hermitte]

boost.program_option et argstream ont leurs imperfections.
boost.program_option avait encore des erreurs dans sa doc il y a un an.

[alexrtz]

Salut,

Je cherche le meilleur parseur d'arguments de la ligne de commande, s'il existe, avant d'être obligé de m'en farcir un. Alors si vous en connaissez qui sont codés proprement, qui sont puissants et surtout intuitifs, merci d'en faire part.

Perso j'aime beaucoup program_options.
J'avais rajouté une surcouche pour l'enregistrement automatique des options.
En gros, pour chaque classe qui avait besoin d'options, fallait "juste" dire quelles étaient les variables à remplir, donner les valeurs par défaut et le texte d'aide.
Les classes s'enregistraient auprès du parseur au démarrage du programme.
Y avait possibilité de facultativiser des options, de prioriser une option si elle était donnée sur la ligne de commande plutôt que dans le fichier de conf, ...

[maxim_um]

Salut rurouni alex,

Je n'ai pas compris ce que tu voulais dire par "enregistrement automatique", mais comme tu le sous-entends, Boost.Program_options, tel qu'il est, ne peut vraisemblablement pas satisfaire tout le monde. Certaines lignes de code révèlent un point de vue intéressant sur le plan conceptuel ou analytique, ça peut être une source d'inspiration, mais cela m'étonnerait fort que je l'utilise comme base de travail pour un parseur. J'ai aussi l'impression que le code a été remanié de nombreuses fois et il faudrait faire une comparaison avec les précédentes versions (<1.39.0), cela dit, ce ne sera peut-être pas d'une grande utilité.

Avec toutes ces lumières, la conclusion s'impose d'elle-même, le meilleur parseur d'arguments de la ligne de commande n'existe pas (encore).

Merci à tous.

[alexrtz]

Je n'ai pas compris ce que tu voulais dire par "enregistrement automatique"

En gros t'as une classe qui gère la lecture des options (par fichier de conf et ligne de commande) et toutes les classes qui ont besoin d'options lui disent "j'ai besoin que tu me lises tel paramètre".
L'avantage c'est que quand tu ajoutes une nouvelle classe A, tu n'as rien à changer dans celle qui lit les options pour prendre en compte les nouvelles options dont a besoin A, il faut juste les indiquer dans cette dernière.

Avec toutes ces lumières, la conclusion s'impose d'elle-même, le meilleur parseur d'arguments de la ligne de commande n'existe pas (encore).

Ben selon l'usage que tu veux en faire y en a forcément un meilleur que les autres

[maxim_um]

Oui, tu n'as pas tort, cependant un parseur est censé couvrir une majorité d'usages potentiels et ainsi "accélérer le développement". Je me vois mal perdre mon temps et jongler avec 4 ou 5 Lib différentes si, d'un programme à l'autre, mes besoins changent. Peut être que je suis trop exigeant, je ne sais pas. Mais l'idée à la base, c'était de trouver un parseur qui soit en mesure de remplacer parfaitement chaque analyseur syntaxique de chaque programme.

Comme il n'y a rien d'urgent, je laisse mûrir la chose et s'il y a des suggestions dans la foulée, ce serait un plus. En ce qui me concerne, dès que j'en aurais l'occasion, je ferais une synthèse de mes besoins avant de tenter d'en faire une extrapolation plus généraliste. Ensuite, pourquoi pas, établir quelques pistes de réflexion qui pourrait faire office de cahier des charges comme la suggéré Luc Hermitte. Et enfin, peut être, terminer avec "Class".

Merci bien.