wie kann ich am einfachsten kommandozeilenoptionen parsen? stringstream, oder geht es besser?

Es geht deutlich besser: http://www.boost.org/doc/libs/1_43_0/doc/html/program_options.html

Ja, das ist praktisch. Aber ist das heutzutage noch guter C++ - Stil, Operatoren auf solch unintuitive Weise zu überladen? Zum beispiel das klammer-hintereinander-konstrukt sieht doch merkwürdig aus.

(ich habe die letzten paar Jahre kaum C++ geschrieben und bin nicht ganz auf dem Laufenden. Könnt ihr Literatur zu boost / dem neuen standard empfehlen?)

ist das heutzutage noch guter C++ - Stil, Operatoren auf solch unintuitive Weise zu überladen? Zum beispiel das klammer-hintereinander-konstrukt sieht doch merkwürdig aus.

Nein, das ist was relativ normales - ich frage mich allerdings auch, wie da eine "intuitive" Überladung aussehen sollte

ich frage mich allerdings auch, wie da eine "intuitive" Überladung aussehen sollte

Wenn einem keine natürliche Überladung einfällt, kann man's vielleicht auch mal ohne frickel frickel frickel machen.
Aber ist hier egal, denn das Kommandozeilenoptionenparsen ist ja recht unabhängig vom Rest und es ist kein Schaden, was Verspieltes, was Altes, was Neues oder so zu nehmen. Hauptsache, man hat nicht das Gefühl, daß es zu schlechter Wartbarkeit führt. Ich denke, das muß man hier überhaupt nicht befürchten.

Nein, das ist was relativ normales - ich frage mich allerdings auch, wie da eine "intuitive" Überladung aussehen sollte

Aus Sichtweise des Lambda-Kalküls ist diese Definition doch ziemlich super. Man kanns ja so interpretieren, dass der op() eine neue Funktion zurückgibt.

Nein, das ist was relativ normales - ich frage mich allerdings auch, wie da eine "intuitive" Überladung aussehen sollte

beispiel für ein "intuitives" (mit anführungsstrichen*) interface: http://docs.python.org/library/optparse.html

ich fände es z.B. bereits intuitiver wenn operator() durch add() ersetzt würde.

---
* intuitivität liegt im auge des betrachters.

Boost kannst du meines Wissens komplett in die Tonne kloppen.

ich fände es z.B. bereits intuitiver wenn operator() durch add() ersetzt würde.

üpsiLohn schrieb:

Eine einfache Funktion mit aussagekräftigem Namen macht das ganze schon viel lesbarer als ein Operator bei dem man raten muss was er bedeuten kann. Aber die Boosttypen stehen halt auf so gefrickel.

Witzig, wie die grössten Kritiker oft keine Ahnung von der Materie haben:
http://www.boost.org/doc/libs/1_43_0/doc/html/boost/program_options/options_description.html#id901318-bb

Ui, es gibt eine Funkion mit dem Namen add ! Einzige Kritik, welche man hier erheben könnte, sind die Fehlenden Überladungen von add , welche bei options_description_easy_init und dem operator() bereits vorhanden sind. Kann man sich aber mit ein paar freien Funktionen einfach Abhilfe schaffen.

Könnte man grundsätzlich auch mal dem Autoren der Bibliothek melden, vielleicht würden sie es sogar reinnehmen. Wahrscheinlich hat es bisher einfach niemand kritisiert.

Grüssli

BesserNichtWisser schrieb:

ich fände es z.B. bereits intuitiver wenn operator() durch add() ersetzt würde.

üpsiLohn schrieb:

Eine einfache Funktion mit aussagekräftigem Namen macht das ganze schon viel lesbarer als ein Operator bei dem man raten muss was er bedeuten kann. Aber die Boosttypen stehen halt auf so gefrickel.

Witzig, wie die grössten Kritiker oft keine Ahnung von der Materie haben:
http://www.boost.org/doc/libs/1_43_0/doc/html/boost/program_options/options_description.html#id901318-bb

Jetzt bin ich mit einer halben Zeile Kommentar schon der größte Kritiker, ich fühle mich geehrt. Es tut mir Leid dass ich nur einmal drei Kommandozeilenoptionen einlesen wollte und meine Erfahrung kommentiere, und nicht ein Diplom mit Nebenfach boost.program_options gemacht habe

Was mich jedoch erstaunt ist die Komplexität der Bibliothek für ein derart triviales Problem. Das an sich ist schon ein valider Kritikpunkt.

Jetzt bin ich mit einer halben Zeile Kommentar schon der größte Kritiker, ich fühle mich geehrt.

Das war eine ganz allgemein gehaltene Aussage.

BesserNichtWisser schrieb:

Es tut mir Leid dass ich nur einmal drei Kommandozeilenoptionen einlesen wollte und meine Erfahrung kommentiere, und nicht ein Diplom mit Nebenfach boost.program_options gemacht habe

Was mich jedoch erstaunt ist die Komplexität der Bibliothek für ein derart triviales Problem. Das an sich ist schon ein valider Kritikpunkt.

Für 3 Kommandozeilenoptionen ist boost::program_options auch der völlige Overkill. boost::program_options ist für Programme gedacht, welche deutlich mehr Optionen haben.

Grüssli

üpsiLohn schrieb:

Eine einfache Funktion mit aussagekräftigem Namen macht das ganze schon viel lesbarer als ein Operator bei dem man raten muss was er bedeuten kann. Aber die Boosttypen stehen halt auf so gefrickel.

Witzig, wie die grössten Kritiker oft keine Ahnung von der Materie haben:
http://www.boost.org/doc/libs/1_43_0/doc/html/boost/program_options/options_description.html#id901318-bb

Das war eine ganz allgemein gehaltene Aussage die immer gilt und nichts mit diesem Parser zu tun hat. Übrigens hast du vergessen volkard als ahnungslosen Kritiker aufzuführen.

Das war eine ganz allgemein gehaltene Aussage die immer gilt und nichts mit diesem Parser zu tun hat.

Haargenau, sieht man sehr oft in RudP.

üpsiLohn schrieb:

Übrigens hast du vergessen volkard als ahnungslosen Kritiker aufzuführen.

Wieso sollte ich? Ist doch nicht der Fall. Volkard hat auf die Aussage von pumuckl reagiert und ich fand diese Antwort sehr korrekt und berechtigt.

Du und BesserNichtWisser habt dagegen nur kritisiert, dass es keine add Funktion geben soll. Wobei du dich sogar noch über die Boost-Leute ausgelassen hast, was hier völlig fehl am Platz ist. Daher habe ich euch zwei korrigiert. Ich hoffe, dass ihr euch dadurch nicht gekränkt fühlt, korrigiert zu werden

Grüssli

So und nu kriegen wir uns bitte wieder ein und diskutieren sachlich das Thema.
Wenn boost für 3 CL-Parameter overkill ist (eine durchaus berechtigte Meinung), gibts evtl. noch andere, leichtgewichtige Libs für sowas?

Ist sowas überhaupt nötig? Man könnte auch ein eigener kleiner Code erstellen, welcher explizit auf diese 3 CL-Parameter ausgelegt ist. Erscheint mir irgendwie einfacher, als dazu extra eine Bibliothek zu nehmen.

Um eine genauere Aussage über das beste Vorgehen zu machen, müsste man vielleicht ein wenig mehr über diese 3 CL-Parameter wissen. Wie sehen die aus? wie soll man sie verwenden können?

Grüssli

üpsiLohn schrieb:

Übrigens hast du vergessen volkard als ahnungslosen Kritiker aufzuführen.

Wieso sollte ich? Ist doch nicht der Fall. Volkard hat auf die Aussage von pumuckl reagiert und ich fand diese Antwort sehr korrekt und berechtigt.

Du und BesserNichtWisser habt dagegen nur kritisiert, dass es keine add Funktion geben soll.

Wo steht bei mir was von einer add Funktion? Ich hab genau wie volkard das unnötige gefrickel kritisiert, das alles nur unleserlich macht.

#include <cxxtools/arg.h>
#include <iostream>
int main(int argc, char* argv[])
{
  cxxtools::Arg<unsigned> number(argc, argv, 'n', 10); // Option -n Zahl mit Default 10
  cxxtools::Arg<bool> verbose(argc, argv, 'v');  // Option -v

  if (verbose)
  {
    std::cout << "es wurde verbose ausgewaehlt" << std::endl;
  }

  for (unsigned n = 0; n < number; ++n)
    std::cout << "Hallo Welt!" << std::endl;

  // argc/argv wird von der Arg-Klasse angepasst, so dass die ausgewerteten Parameter entfernt werden:
  if (argc <= 1)
    std::cout << "es wurden keine weiteren Kommandozeilenparameter uebergeben" << std::endl;
}

Das Template ist unter http://www.tntnet.org/download/cxxtools-1.4.8/include/cxxtools/arg.h zu finden. Ich persönlich finde meine Klasse einfacher als die boost Variante, aber ich bin natürlich nicht unparteiisch .