int main(int argc, char **argv)

Reeko25

Kann mir mal jemand leicht verständlich erklären vor für

int main(int argc, char **argv)

steht. Vielen Dank!

Skym0sh0

das ist der eintrittspunkt, also der start, deines programms
das ist eine funktion die ganz am anfang aufgerufen wird.

Skym0sh0 schrieb:

das ist eine funktion die ganz am anfang aufgerufen wird

, vom Betriebssystem.

Zu den Parametern: Wenn du dein Programm von der Kommandozeile aus startest, dann kannst du ihm Argumente/Parameter übergeben. Die Anzahl der Parameter steht in argc und die Werte (Zeichenketten) stehen in argv.

wxSkip

Und mit

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

kannst du noch einfacher und moderner auf die Argumente zugreifen.

SeppJ

wxSkip schrieb:

Und mit
int main(int argc, char **argv)
{
    std::vector<std::string> args(argv, argv + argc);
}
kannst du noch einfacher und moderner auf die Argumente zugreifen.

Habt ihr das gerade auch gehört? Ich glaube das war das Geräusch von Reeko25, wenn er nichts mehr versteht.

wxSkip

SeppJ schrieb:

wxSkip schrieb:
Und mit
int main(int argc, char **argv)
{
    std::vector<std::string> args(argv, argv + argc);
}
kannst du noch einfacher und moderner auf die Argumente zugreifen.
Habt ihr das gerade auch gehört? Ich glaube das war das Geräusch von Reeko25, wenn er nichts mehr versteht.

volkard

wxSkip schrieb:

Und mit
int main(int argc, char **argv)
{
    std::vector<std::string> args(argv, argv + argc);
}
kannst du noch einfacher und moderner auf die Argumente zugreifen.

Den Trick würde ich mal weglassen. Den kann man gut genug noch nehmen, FALLS er mal sinnvoll eingesetzt werden kann. Aber als Default würde ich ihn nicht empfehlen.

wxSkip

volkard schrieb:

wxSkip schrieb:
Und mit
int main(int argc, char **argv)
{
    std::vector<std::string> args(argv, argv + argc);
}
kannst du noch einfacher und moderner auf die Argumente zugreifen.
Den Trick würde ich mal weglassen. Den kann man gut genug noch nehmen, FALLS er mal sinnvoll eingesetzt werden kann. Aber als Default würde ich ihn nicht empfehlen.

Ich vermute mal, die meisten Programme, denen so etwas nicht gut tun würde, können auch gleich int main() schreiben.

Das würde ich so nicht sagen. In der Regel schmeißt man die Parameter ja ziemlich direkt in getopt oder Vergleichbares, und da wird selten (nie?) ein std::vectorstd::string erwartet.

wxSkip

seldon schrieb:

Das würde ich so nicht sagen. In der Regel schmeißt man die Parameter ja ziemlich direkt in getopt oder Vergleichbares, und da wird selten (nie?) ein std::vectorstd::string erwartet.

getopt habe ich bisher kaum gehört. Mir ist zwar schon mal so etwas wie wxCommandLineParser über den Weg gelaufen, aber ich bin bisher eher ein Freund von selbst Parsen (wenn man seine Argumente denn "Parsen" muss).

Getopt ist ein im POSIX-Standard festgeschriebenes System zur Verarbeitung von Kommandozeilen. wxCmdLineParser (welches übrigens auch argc und argv nackt erwartet) ist getopt ziemlich ähnlich. Es sollte mich nicht wundern, wenn die auf POSIX-Systemen getopt als Backend benutzten.

Ansonsten zieht hier, denke ich, POLA. Gerade, wenn auch mal eine recht komplexe Optionsphalanx angegeben werden kann, macht es eine Menge Sinn, sich an etablierte Standards zu halten. Eigene Fummelparser sind da in meiner Erfahrung eher selten hilfreich.

Dravere

wxSkip schrieb:

seldon schrieb:

Das würde ich so nicht sagen. In der Regel schmeißt man die Parameter ja ziemlich direkt in getopt oder Vergleichbares, und da wird selten (nie?) ein std::vectorstd::string erwartet.

getopt habe ich bisher kaum gehört. Mir ist zwar schon mal so etwas wie wxCommandLineParser über den Weg gelaufen, aber ich bin bisher eher ein Freund von selbst Parsen (wenn man seine Argumente denn "Parsen" muss).

Aber wenn du die Argumente nur einliest, dann musst du daraus doch kein std::vector mit std::string Objekten machen. Ich sehe da keinerlei Zweck. All diese Speicherallokationen und Kopien, nur um über ein "schöneres" Interface darauf zugreifen zu können, ist schon sehr fragwürdig. Wenn du willst, kannst du ja eine Klasse string_literal erstellen, welche dir ein paar Hilfsmittel zur Verfügung stellt. Du kannst auch noch eine array_wrapper<string_literal> Klasse machen.

Und wenn es komplexer wird kannst du auch gleich z.B. Boost.ProgramOptions nehmen. Selber machen tut man nur für sehr einfache Dinge.

Grüssli

volkard

wxSkip schrieb:

aber ich bin bisher eher ein Freund von selbst Parsen (wenn man seine Argumente denn "Parsen" muss).

Ich auch, nuß ich zugeben. Und da bringt mir std::string gar keine Vorteile. Ich werte mal nicht als Vorteil, daß ich mit == vergleichen darf.

314159265358979

Dravere schrieb:

Wenn du willst, kannst du ja eine Klasse string_literal erstellen, welche dir ein paar Hilfsmittel zur Verfügung stellt. Du kannst auch noch eine array_wrapper<string_literal> Klasse machen.

Solche Dinge habe ich desöfteren vermisst. Eine Art weak_string. Für Standardcontainer wäre das vielleicht auch praktisch.
Warum gibts sowas noch nicht?

wxSkip

volkard schrieb:

wxSkip schrieb:

aber ich bin bisher eher ein Freund von selbst Parsen (wenn man seine Argumente denn "Parsen" muss).

Ich auch, nuß ich zugeben. Und da bringt mir std::string gar keine Vorteile. Ich werte mal nicht als Vorteil, daß ich mit == vergleichen darf.

Na gut. Wertest du find_first_of(), substr() und Konsorten als Vorteil?

Dravere

wxSkip schrieb:

volkard schrieb:

wxSkip schrieb:

aber ich bin bisher eher ein Freund von selbst Parsen (wenn man seine Argumente denn "Parsen" muss).

Ich auch, nuß ich zugeben. Und da bringt mir std::string gar keine Vorteile. Ich werte mal nicht als Vorteil, daß ich mit == vergleichen darf.

Na gut. Wertest du find_first_of(), substr() und Konsorten als Vorteil?

Dazu brauchst du doch keinen std::string . Schau dir mal <algorithm> an. Daher ist auch die Implementation einer string_literal Klasse oder dergleichen verdammt einfach.

314159265358979 schrieb:

Warum gibts sowas noch nicht?

Weil es wahrscheinlich zu wenig benötigt wird. Ich habe dies jedenfalls noch nicht desöfteren vermisst. Ich habe es sogar, glaube ich, noch nie vermisst.

Grüssli

Nexus

Dravere schrieb:

Ich sehe da keinerlei Zweck. All diese Speicherallokationen und Kopien, nur um über ein "schöneres" Interface darauf zugreifen zu können, ist schon sehr fragwürdig.

Sonst gehst du gegen solche Sätze immer mit der Premature-Optimization-Keule vor, und jetzt schreibst du sie selbst?

Wenn ich genau die Funktionalität von std::string brauche und wenn das Einlesen der Parameter nicht den Grossteil der Rechenzeit ausmacht (was sehr wahrscheinlich ist), baue ich mir sicher keine string_literal -Klasse...