int main(std::vector<std::string> args)
{}

Is mir nur vorhin mal so in den Sinn gekommen :p

Wann bekommen wir eigentlich mal eine C++ main?

Nie...

int TheModernMain(std::vector<std::string> args);

int main(int argc, char** argv)
{
    return TheModernMain( Transmogrify(argc, argv) );
}

int main(int argc, char** argv)
{
  std::vector<std::string> commandline(argv, argv+argc);
}

edit: Zu spät...

Klar geht sowas^^. Ich meinte ja nur mal... wäre vielleicht mal an der Zeit.

Genau, denn der Mehrwert der "C++ main" ist unbeschreiblich und der C++ Standard würde nach der notwendigen Ergänzung schön schlank bleiben...

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.

warum schreibst du nicht einfach

int main(int argc, char *argv)

Ah, ok. Das schreibe ich ab jetzt immer so.

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.

Fast. Es müsste +(argc+1) sein. Sonst fehlt da ein Parameter.

Nein, warum?

Fast. Es müsste +(argc+1) sein. Sonst fehlt da ein Parameter.

Du hast verstanden, wie Iteratoren funktionieren.

Man kann auch normal antworten.

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

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

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?

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