Parameter überprüfen
-
Ich will ein Programm schreiben, dass je nach Parameter (z.B. C:\programm.exe -u) etwas anderes macht. Wie finde ich am besten den jeweiligen Parameter heraus und starte die entsprechende Funktion?
Bisherige Versuche:
if/else: funktioniert gut, man kann die Parameter mit strcmp kontrollieren und dementsprechen andere Funktionen starten. Nachteil: Unübersichtlich und lang, wenn mehrere Funktionen verwendet werden.else if (strcmp(szParam[1],"-u") == 0) funktion1(); else if (strcmp(szParam[1],"-a") == 0) funktion2();
switch/case: man kann zwar auf den zweiten Buchstaben (z.B. u) prüfen. Ist aber etwas unsauber. Dafür wäre aber dieses Vorgehen übersichtlicher.
switch (szParam[1][1]) { case 'u': funktion1(); break; ...
Wie würdet ihr es machen? Oder gibts da andere elegantere Möglichkeiten?
-
for(i = 1; i < argc; ++i) { if (!strcmp(argv[i], "-u")) printf("--U <%s>\n", argv[++i]); else if (!strcmp(argv[i], "-a")) printf("--A <%f>\n", atof(argv[++i])); }
foobar -u "hallo welt" -a 3.14159265359 -a 2.718281828 -u "foo bar baz"
-
Zugriff auf "szParam[1][1]" kann natürlich schon in die Hose gehen...
Mal so als Idee (nehme ich immer als Basis):
/* scan calling parameter list */ ret = 0; ix = 1; while ((ix < argc) && (ret >= 0)) { if (strcmp(argv[ix],"-T") == 0) { testmode = TRUE; } elsif ((strcmp(argv[ix],"-D") == 0) && ((ix + 1) < argc)) { ix++; if (strncmp(argv[ix],"0x",2) == 0) sscanf(&argv[ix][2],"%x",&dbgmode); else sscanf(argv[ix],"%d",&dbgmode); } elsif ((strcmp(argv[ix],"-log") == 0) && ((ix + 1) < argc)) { ix++; logfile = fopen(argv[ix],"a"); } elsif ((strcmp(argv[ix],"-dbg") == 0) && ((ix + 1) < argc)) { ix++; dbgfile = fopen(argv[ix],(dbgmode&DBG_CREADBGFILE?"w":"a")); } elsif ((strcmp(argv[ix],"-cfg") == 0) && ((ix + 1) < argc)) { ix++; cfgfile = fopen(argv[ix],"r"); } elsif (strcmp(argv[ix],"-version") == 0) ret = -1; elsif (strcmp(argv[ix],"-teststart") == 0) teststartflg = TRUE; elsif ((strcmp(argv[ix],"-?") == 0) || (strcmp(argv[ix],"-help") == 0)) ret = -1; elsif (argv[ix][0] != '-') { /* exit if POST calls fwd with http parameter */ /* ignore parameter list */ break; } else { sprintf(hstr,"*** error scanning parameter %d \"%s\" ***\n",ix,argv[ix]); usage(argv[0],hstr); goto errex; } ix++; } /* any error => usage message and exit */ if (ret < 0) { usage(argv[0]); ret = -100; goto errex; }
... läßt sich natürlich entsprechend anpassen.
P.S.: Code ist in Wirklichkeit natürlich eingerückt. Irgendwas klappt hier mit den Tab's nicht.
P.P.S. ach so, für "elsif" gilt: "#define elsif else if". Ist einfach praktisch
-
jox schrieb:
P.P.S. ach so, für "elsif" gilt: "#define elsif else if". Ist einfach praktisch
naja, 2 zeichen gespart. hast wohl zu viel mit perl/php gecodet?
-
net schrieb:
jox schrieb:
P.P.S. ach so, für "elsif" gilt: "#define elsif else if". Ist einfach praktisch
naja, 2 zeichen gespart. hast wohl zu viel mit perl/php gecodet?
Würd mich auch ankotzen, allein wegen keinem highlighting.
-
jox schrieb:
P.P.S. ach so, für "elsif" gilt: "#define elsif else if". Ist einfach praktisch
find ich hässlich
Greetz, Swordfish
-
Dass keiner über das goto meckert wundert mich jetzt aber schon
-
Diamond schrieb:
Dass keiner über das goto meckert wundert mich jetzt aber schon
ich finde goto's okay.
-
http://www.galileo-press.de/openbook/c_von_a_bis_z/c_010_011.htm
u goto, naja was findest du daran toll? Aus Schleifen u.ä. kommt man wenn sie logisch erstellt worden doch immer irgendwie raus, auch ohne goto!
-
Diamond schrieb:
goto, naja was findest du daran toll? Aus Schleifen u.ä. kommt man wenn sie logisch erstellt worden doch immer irgendwie raus, auch ohne goto!
Ich finde goto's auch doof. In Schleifen sind "break" und "continue" auch nichts anderes als goto's. Ein "return(..)" irgendwo mitten in einer Funktion ist ebenfalls ein verstecktes goto. Wie gesagt, auch das finde ich doof.
In absoluten Fehlersituationen, wo man nicht vernünftig weiterkommt, halte ich persönlich es vertretbar, ans Funktionsende zu springen. Das kann den Code sogar übersichtlicher gestalten. Selbstverständlich könnte man hier auch ein "return()" machen, dann hat man aber Probleme, wenn man (a) beim Debuggen einen Breakpoint beim Verlassen der Funktion setzen will bzw. wenn man (b) grundsätzlich Trace-Funktionen am Funktionsende vorsieht.
Es gibt halt unterschiedliche Programmierstile, und da steckt viel Philosophie hinter... Soll halt jeder machen, wie er will... (oder sind wir hier in der Schule?)
Doof finde ich es auch, sich über das Coding von anderen Leuten aufzuregen, wenn das mit der eigentlichen Fragestellung nichts zu tun hat und auch nicht zur Problemlösung beiträgt.