C++ main
-
Die gängigen Frameworks zur Verarbeitung von Kommandozeilenparametern erwarten
allesamt char** und int. Ich habe zwar keine Zweifel daran, dass boost.program_options schnell ein entsprechendes Interface zusammen hätte, sollte eine Signatur von main dieser Form im Standard auftauchen, aber im Grunde müsste sich diese Lösung erst das Problem schaffen, das sie lösen soll. Ich schaudere auch bei dem Gedanken, unschuldige C++-Programmierer dabei zu sehen, wie sie die Parameter wieder aus dem Vektor kopieren, um getopt zufriedenzustellen.Dazu kommt, dass diese Form von main nur benutzt werden könnte, wenn <string> und <vector> eingebunden werden - jedenfalls, sofern du nicht den Java-Weg gehen willst, dass bestimmte Header generell eingebunden werden, worüber Entwickler mit großen Projekten, die auf die Dauer des Kompilationsvorgangs achten, laut fluchen dürften. Außerdem liegen weitere Unannehmlichkeiten in dieser Route - schon bald hast du implizite toString-Methoden und Namensräume, die implizit benutzt werden. Ich finde es schwer, eine vernünftige Erklärung zu finden, warum main zwei #includes benötigen sollte, ohne mir selbst zu entgegnen: "Wenn es dir so wichtig ist, warum schreibst du nicht einfach
#include <vector> #include <string> int do_main(std::vector<std::string> args); int main(int argc, char *argv) { return do_main(std::vector<std::string>(argv, argv + argc)); }in einen Header und statt main
#include "main.inl" int do_main(std::vector<std::string> args) { // Programm hier }?"
Denn eine Implementation, die das Verhalten erzeugte, müsste sowieso so oder ähnlich vorgehen - du kannst dir möglicherweise den Aufschrei unter Shell-Entwicklern vorstellen, sollte man versuchen, die Aufrufskonventionen von Programmen in dieser Richtung zu verändern.
Geschenkt, dass char** eine archaische Form der String-Übergabe ist - der Kram liegt halt eh in dieser Form vor, und es ist wirklich kein Problem, ihn in einen Vektor zu stopfen, wenn man das will. Um eine Zeile Code zu sparen in einem Anwendungsfall, der eh fast nie auftritt, muss man nun wirklich nicht den Standard ändern.
-
seldon schrieb:
warum schreibst du nicht einfach
int main(int argc, char *argv)Ah, ok. Das schreibe ich ab jetzt immer so.
-
Äh, jaaaa...*hust* Da hab ich wohl ein [] vergessen.
-
Shlo schrieb:
int main(int argc, char** argv) { std::vector<std::string> args(argv, argv + argc); // ... }Fast. Es müsste +(argc+1) sein. Sonst fehlt da ein Parameter.
-
krümelkacker schrieb:
Fast. Es müsste +(argc+1) sein. Sonst fehlt da ein Parameter.
Nein, warum?
-
krümelkacker schrieb:
Fast. Es müsste +(argc+1) sein. Sonst fehlt da ein Parameter.
-
Shlo schrieb:
Man kann auch normal antworten.
-
krümelkacker schrieb:
Shlo schrieb:
int main(int argc, char** argv) { std::vector<std::string> args(argv, argv + argc); // ... }Fast. Es müsste +(argc+1) sein. Sonst fehlt da ein Parameter.
Im c ist die +1 enthalten

-
Zeus schrieb:
krümelkacker schrieb:
Shlo schrieb:
int main(int argc, char** argv) { std::vector<std::string> args(argv, argv + argc); // ... }Fast. Es müsste +(argc+1) sein. Sonst fehlt da ein Parameter.
Im c ist die +1 enthalten

Stimmt! Ich kann mir das nie merken, was der Wert von argc bedeutet.
@Shlo: Ja sicher. Da lag das Problem aber nicht. :p
-
krümelkacker schrieb:
Stimmt! Ich kann mir das nie merken, was der Wert von argc bedeutet.
@Shlo: Ja sicher. Da lag das Problem aber nicht. :p
Du kannst dir nicht merken, was der Wert von argc bedeutet? Really?

-
Shlo schrieb:
Du kannst dir nicht merken, was der Wert von argc bedeutet? Really?

Genau. Aber vielleicht bleibt's ja diesmal hängen. Wenn man argv[0] nicht als "Argument" mitzählt, kann das schonmal vorkommen. Und so abwägig ist das nicht; denn das erste "Programm-Argument" befindet sich ja in argv[1] (bei entsprechender Definition von "Argument"). Ein "Du hattest Recht, ich hatte Iteratoren nicht verstanden" kann ich Dir nicht anbieten, da es nicht der Wahrheit entspricht.
kk