Mögliche Duplizieren:
What parameter parser libraries are there for C++?Option Parser für C/C++?
Ich habe eine ganze Reihe von Bibliotheken für die Befehlszeilenoption Parsing einige suchen und es gibt getan, aber es ist schwierig, zwischen ihnen zu unterscheiden. Hat jemand irgendwelche Erfahrung mit irgendwelchen von ihnen? Ist einer härter/besser/schneller/leichter/wie auch immer? Oder sollte ich einfach mein eigenes wachsen lassen?
Wenn Sie mit Linux/Unix dann Getopt ist der Optionsparser für Sie es. funktioniert auf fast allen Aromen von Unix und ist einfach zu bedienen
Für viele Zwecke sind die GNU getopt() und getopt_long() Funktionen eine gute Wahl. Die GNU getopt() ist für einbuchstabige Optionsargumente gedacht und nähert sich dem POSIX-Standardverhalten ziemlich genau an. Sie kann dazu gebracht werden, sich orthodoxer zu verhalten, indem sie die Umgebungsvariable POSIXLY_CORRECT setzt. Der Unterschied besteht darin, dass GNU Optionsargumente nach dem ersten Nicht-Optionsargument erkennt und die Argumente so permutiert, dass alle Optionsargumente vor einem der Nicht-Optionsargumente verarbeitet werden. Das ist manchmal wichtig - obwohl die Kontexte dazu neigen, ein wenig esoterisch zu sein. Es gibt ein paar andere zusätzliche Tricks zur Verfügung.
Die GNU getopt_long() ist der beste Mechanismus für den Umgang mit langen Optionen wie --help. Es kann mit optionalen Argumenten, passenden Ein-Buchstaben-Optionen und allen möglichen Dingen umgehen.
Es gibt zahlreiche andere Pakete, die Optionen auf verschiedene Arten handhaben.
(Perl hat eine Fülle von Getopt Module, was, wie viel Aufwand wurde im Laufe der Jahre setzen in.)
Sie könnten einige nützliche zusätzliche Informationen zu What is the general syntax of a Unix shell command finden. Sie können auch die POSIX-Spezifikation für Befehlszeilenkonventionen im Kapitel Utility Conventions lesen.
Es gibt nur eine schlechte Sache über GNU getopt() und es ist die Lizenz. – Anonymous
Ja - es ist zumindest LGPL in diesen Tagen. Früher war es eine vollständige GPL. Sie können Nicht-GNU-Versionen von getopt() erhalten. AT & T veröffentlichte die Quelle beispielsweise auf UseNet-Weg zurück. –
Eine gute Spezifikation, wie die POSIX-Dienstprogramme funktionieren, finden Sie im Kapitel POSIX [Utility Conventions] (http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html). –
Wenn Sie etwas völlig plattformübergreifend wollen, habe ich die Boost::Program_Options Bibliothek als sehr gut gefunden. Es gibt etwas von einer Lernkurve, um es einzurichten, aber sobald Sie das beherrschen, vereinfacht es die Dinge sehr.
Das Schlimme an dieser Bibliothek ist, dass es im Gegensatz zu den meisten anderen Komponenten von Boost kein "nur Header" ist. Ich habe nie wirklich verstanden, warum das so ist. – becko
Nur weil der Entwickler es so gemacht hat. Ich bin davon weniger verliebt, seit ich das auch geschrieben habe. Es ist gut und plattformübergreifend, aber ich finde, dass ich die Handhabung der Optionen meistens mit meinem eigenen Code bevorzuge. Die Zeit, die ich brauche, um einen Optionsparser von Grund auf zu schreiben, ist oft geringer als das, was es kostet, herauszufinden, wie ich den Bibliothekscode für die gleiche Sache einstelle, vor allem, weil ich mich nicht mit Konfigurationsdateien beschäftigen muss. nur Befehlszeilenoptionen. –
Die Tatsache, dass Boost :: Program_Options keine Header-Only-Funktion ist, ist ein Problem, da Boost die Version häufig aktualisiert. Das heißt, wenn Sie nicht statisch mit Boost :: Program_Options verknüpfen, wird Ihr Programm nicht auf allen Rechnern mit der falschen Version von Boost laufen! – becko
Ich benutze die System-Implementierung von getopt_long() für die meisten Dinge, aber Sie müssen möglicherweise tragbarer sein, die die Verwendung solcher POSIX-Kreatur Komfort verbietet.
Here is the standard In Bezug auf die POSIX-Ansicht von Befehlszeilenoptionen, wenn Sie sich in einer Position befinden, in der getopt()/getopt_long() nicht verfügbar ist und Ihre eigenen rollen müssen. Vielleicht möchten Sie auch einen Blick darauf werfen, was POSIX über Hilfe-/Optionszusammenfassungsanzeigen zu sagen hat (ich kann keinen Link zu diesem Teil des Standards finden).
Persönlich mag ich nicht mit Programmen, die nicht --long-Optionen, weil die Erinnerung an die kurzen Optionen ist ein Schmerz und keine zwei Programme verwenden das gleiche.
boost::program_options ist ziemlich gut und hat eine nette C++ - Schnittstelle, die prüfen kann, ob Optionsparameter einen bestimmten Typ haben (wie 'int') und sie direkt in Variablen speichern.
Es unterstützt auch das Laden der "Optionen" aus einer Konfigurationsdatei, so dass Sie einen Konfigurationsdateiparser kostenlos erhalten. Auf diese Weise können Sie sehr einfach alle Konfigurationseinstellungen über die Befehlszeile überschreiben oder alle Befehlszeilenoptionen zur Konfigurationsdatei hinzufügen, wodurch sie sehr flexibel ist.
auch dort sind popt.
Stimmen Sie mich für "rollen Sie Ihre eigenen." a) Sie lernen daraus, b) es macht Spaß und c) Sie müssen sich keine Gedanken über die Portabilität oder den Code anderer machen, und d) Sie wissen, dass Sie alle Funktionen haben, die Sie wollen, und keine diejenigen, die du nicht tust. Ich denke jedoch, dass ich in der Minderheit sein werde. –
@Chris Lutz: es sei denn, Sie rollen Ihre eigenen, so dass es sehr nah am Standard hält, dann sind Sie in Gefahr, Programme zu produzieren, die irritierend zu verwenden sind. Die Verwendung eines Standardoptionsparsers reduziert das Lernen für alle anderen (die Ihr Programm verwenden) und vereinfacht normalerweise auch die Wartung. –
Ich gerade erst ausgerollt https://github.com/visionmedia/commander.ca port-ish meiner Ruby und Node Option Parser –