Version imprimable
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.
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.
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.
Salut,
Je te conseille Boost : il est assez complet et très performant.
Petit tuto dispo ici :
tutorial
boost.program_option et argstream ont leurs imperfections.
boost.program_option avait encore des erreurs dans sa doc il y a un an.
Je viens de passer en revue toutes celles que l'on vient d'aborder ici, y compris CLAP. Aucune ne va assez loin à mon gout, je n'aborde même pas les lacunes en ce qui concerne la localisation. Je pense qu'il va falloir mettre la main à la pâte. Maintenant, je me tâte. Est-ce que l'utilisateur lambda préfère utiliser des fonctions/Class ou des templates de fonctions/Class lors d'instanciation d'objets par exemple?
Je pense que l'utilisateur lambda préfère ne rien utiliser du tout :ccool:Citation:
Envoyé par maxim_um
Bien foutue, une template apportera généricité et prospérité.
Un typedef qui va bien ne fait pas de mal non plus
Code:typedef basic_string<char> string;
Si tu te sens de faire une synthèse comparative ou un cahier des charges de ce que tu aimerais y voir dedans, cela pourrait s'avérer instructif.
Très très belle tournure metagoto.Citation:
Envoyé par metagoto
Merci
Je n'ai jamais ressenti le besoin d'utiliser un parseur, et puis un beau matin, je me suis dit que ce serait peut-être utile, au lieu de réécrire pour chaque programme un analyseur. Cela dit, je n'en fais pas tous les jours.Citation:
Envoyé par Luc Hermitte
En postant, j'avais espéré avoir des retours d'expériences, ce qu'ils aiment dans telle Lib, ce qu'ils regrettent, et cætera. Mais comme tu le constates, y'a pas foule.
Beaucoup préfère se taper dessus avec du Linux ou du Windows.
Bon, j'ai balayé puis décortiqué certains passages des différentes sources, (pour Boost, je suis loin d'avoir finie tellement j'ai l'impression que les héritages n'en finissent plus). Certes, j'y ai relevé des lacunes, manques ou imperfections, mais dans le même temps je n'ai pas réfléchi aux problèmes qu'ont pu rencontrer les programmeurs, développeurs à la conception ou pendant l'écriture des sources.
Alors, tu penses bien que je ne peux pas prétendre être un bon critique ou m'autoriser à faire une étude comparative si je ne fais pas l'effort d'implanter ces sources ou Lib dans un projet test. Et là forcément, la motivation serait proportionnellement inverse au facteur temps.
Pour le second point, j'y réfléchis bien que, comme tu la compris, il ne fait pas parti de mes priorités du moment.
Dans tous les cas, tu es le seul à avoir suivi cette discussion avec intérêt, et je t'en remercie infiniment.
Perso j'aime beaucoup program_options.Citation:
Envoyé par maxim_um
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, ...
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.
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".Citation:
Envoyé par maxim_um
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.
Ben selon l'usage que tu veux en faire y en a forcément un meilleur que les autres ;)Citation:
Envoyé par 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.