Kommandozeilenoptionen parsen

pumuckl schrieb:

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.

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.

Hallo,

Boost kannst du meines Wissens komplett in die Tonne kloppen.

mit boost und diesen unmengen an templates kann man auf jeden fall die compilezeit verzehnfachen.

Dravere

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

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

Dravere schrieb:

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.

Janjan

Du unterschätzt die Komplexität des Parsens von Kommandozeilenparameter ganz gewaltig.

Dravere

BesserNichtWisser schrieb:

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

Dravere schrieb:

ü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.

Dravere

üpsiLohn schrieb:

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

pumuckl

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?

Dravere

pumuckl schrieb:

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

Dravere schrieb:

ü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.

tntnet

Für das parsen von Kommandozeilenoptionen habe ich mir schon vor langer Zeit ein paar einfache Helfertemplates gemacht, die mir bereits bei unzähligen Programmen gute Dienste geleistet haben. Selbst meine einfachsten Testprogramm verwenden die Klasse. Hier mal ein Beispiel:

#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 .