[C++] Kommandozeilen-Parameter (argv and env)
-
Es gibt dafür selbstverständlich eine Lib, und zwar in Boost. Heißt glaub ich programm options. (die boost.org Website kann ich zur Zeit leider nicht erreichen)
Die unterstützt dich nicht nur beim verarbeiten sondern auch beim checken von gültigen Parametern und alternativ kann man auch die Params aus einer config-Datei laden und speichern.
-
Ich finde solche Bibliotheken (speziell getopt, was total kryptisch ist) nehmen einem nur Flexibilität und bringens nicht wirklich.
Da scanne ich die Argumente lieber selbst. Ist doch nur ne for-Schleife mit nem switch drin.
-
DrGreenthumb schrieb:
Ich finde solche Bibliotheken (speziell getopt, was total kryptisch ist) nehmen einem nur Flexibilität und bringens nicht wirklich.
Da scanne ich die Argumente lieber selbst. Ist doch nur ne for-Schleife mit nem switch drin.
naja...
ist schon etwas komplizierter wenn du n gutes CLI anbieten willst
-
glaube ich nicht... bin damit bisher jedenfalls immer gut gefahren und biete nur gute CLIs an
-
getopt() und kryptisch? lol!
getopt ist echt bequem. Wenn man erst die manpage/sonstige doku dazu gelesen hat, dann kann man es ainfach benutzen.
-
kenne getopt nicht, sehe das nur hin und wieder und frage mich was der komische "xyz:blablub"-String bedeuten soll...
Aber wenn ich mir jetzt dieses Beispiel aus der Manpage ansehe, bestätigt sich nur meine Meinung. Jede Menge getopt-Kram den man erstmal verstehen muss und am Ende hat man immer noch ne Schleife mit nem switch drin.
-
DrGreenthumb schrieb:
kenne getopt nicht, sehe das nur hin und wieder und frage mich was der komische "xyz:blablub"-String bedeuten soll...
Aber wenn ich mir jetzt dieses Beispiel aus der Manpage ansehe, bestätigt sich nur meine Meinung. Jede Menge getopt-Kram den man erstmal verstehen muss und am Ende hat man immer noch ne Schleife mit nem switch drin.
Wenn man die Doku net gelesen hat, erscheint es kryptisch. Das ist aber noch einfacher als der formatstring von printf...
getopt ist total bequem.
die einzelnen Buchstaben zeigen die möglichen optionen. und wenn nach einem Buchstaben ein ':' kommt, dann übernimmt diese option auch ein argument. Das wars. Mehr muss man net wissen.
-
Ich finde solche Bibliotheken (speziell getopt, was total kryptisch ist)
kenne getopt nicht
-voice
-
Ich benutz boost.program options. Ist anfangs durchaus etwas kryptisch aber wenn man erst einmal verstanden hat wie es funktioniert dann will man nicht mehr ohne.
Da scanne ich die Argumente lieber selbst. Ist doch nur ne for-Schleife mit nem switch drin.
Kommt auf die Argumente an. Flags kannst du beispielsweise direkt an eine bool Variable binden.
("show-scanned-file,S", po::bool_switch(&show_scanned_files), "Prints a message before a file is being processed.")Fertig. Kurz und lange Kommandoversion und Eintrag in --help implementiert. Später im Program braucht man nur noch ein if(show_scanned_files) hinein zu hauen und fertig ist der Lack.
Wenn es nun natürlich drum geht eine Liste zu verarbeiten kommst du natürlich nicht um eine Schleife irgendwo herum. Kannst dafür aber auch for_each nehmen.
Das Parsen selbst zu übernehmen ist wesentlich fehleranfälliger und am Ende hat man doch manche Flags weggelassen weil man zu faul war den Parser umzubauen.
-
Hallo,
danke für die zahlreichen Informationen. Ich würde gerne die CLI-Application die ich schreibe für Win/*BSD/Linux schreiben. Das sollte eigetlich kein Problem sein.
Jeodoch scheiteret es jetzt an "#include <unistd.h>" -> getopt! Kann ich dieses auch unter win nutzen? Wenn ja wo bekomme ich es her.
gruß
zyon
-
Nimm doch boost. Windows hat kein getopt, sollte aber auch nicht das Problem sein, für Windows zu kompilieren, wenns nicht zu sehr mit der glibc verwachsen ist.
omg schrieb:
Ich finde solche Bibliotheken (speziell getopt, was total kryptisch ist)
kenne getopt nicht
-voice
ja nee, kenne es gut genug um mir ne Meinung darüber zu bilden.
Wollte aber auch nicht so auf der "kryptik" rumreiten... meine nur, es lohnt einfach nicht. Es sei denn, man will unbedingt, dass auch -ab statt -a -b funktioniert.
Ben04 schrieb:
Das Parsen selbst zu übernehmen ist wesentlich fehleranfälliger und am Ende hat man doch manche Flags weggelassen weil man zu faul war den Parser umzubauen.
naja, groß parsen muss man ja nicht. Ist immer das gleiche:
for(char** p=argv+1; *p; ++p) if(string(*p)=="-x") xflag = true; ...Das wird auch bei 30 Optionen nicht unübersichtlicher und bleibt einfach erweiterbar.