main-Argumente const-Qualifizieren?



  • Das ist ja doph. Naja, danke für die Antwort.

    Weiß jemand zufällig, welche Compiler so eine main nicht akzeptieren? Unter GCC und MSVC funktioniert es.



  • pumuckl schrieb:

    Heißt: der Standard erlaubt es, aber dein Compiler muss es nicht schlucken.

    Ohne jetzt den Standard zu wälzen: Ist das Problem nicht in der Regel, dass Compiler absolut jede main-Definition schlucken, aber sie nicht unbedingt als korrekten Einsprungpunkt umsetzen? Ich könnte mir z.B. vorstellen, dass int main(vector<string> const& args) erstmal anstandslos geschluckt wird, dann aber zu lustigen Ergebnissen führt.

    edit: Um die Frage nochmal unter diesem Gesichtspunkt neu zu beantworten: Dass der Compiler eine bestimmte zusätzliche Signatur erlaubt, bedeutet, dass er sie korrekt aufrufen kann. Unter Linux gibt es m.W. eine main-Form mit zusätzlichem Zeiger auf die Umgebungsvariablen. Wenn du eine selbst ausgedachte Signatur verwendest, bewegst du dich im undefinierten Bereich. Im Falle von zusätzlichen const-Qualifikationen würde ich erwarten, dass es aufgrund der identischen internen Repräsentation funktioniert, aber das ist halt nicht garantiert.



  • Bashar schrieb:

    pumuckl schrieb:

    Heißt: der Standard erlaubt es, aber dein Compiler muss es nicht schlucken.

    Ohne jetzt den Standard zu wälzen: Ist das Problem nicht in der Regel, dass Compiler absolut jede main-Definition schlucken, aber sie nicht unbedingt als korrekten Einsprungpunkt umsetzen? Ich könnte mir z.B. vorstellen, dass int main(vector<string> const& args) erstmal anstandslos geschluckt wird, dann aber zu lustigen Ergebnissen führt.

    Naja, ich lese das in §3.6.1 so: Es MUSS eine main im Programm geben, die der Einstiegspunkt des Programms ist. main darf nicht überladen werden. Soll heißen, es darf exakt eine Funktion main geben. Diese Funktion ist der Einstiegspunkt. Wenn eine Implementation das vermurkst, ist die Implementation nicht konform.

    edit: Um die Frage nochmal unter diesem Gesichtspunkt neu zu beantworten: Dass der Compiler eine bestimmte zusätzliche Signatur erlaubt, bedeutet, dass er sie korrekt aufrufen kann.

    Ja.

    Wenn du eine selbst ausgedachte Signatur verwendest, bewegst du dich im undefinierten Bereich.

    Dann sollte der Compiler das bemängeln.



  • pumuckl schrieb:

    Naja, ich lese das in §3.6.1 so: Es MUSS eine main im Programm geben, die der Einstiegspunkt des Programms ist. main darf nicht überladen werden. Soll heißen, es darf exakt eine Funktion main geben. Diese Funktion ist der Einstiegspunkt. Wenn eine Implementation das vermurkst, ist die Implementation nicht konform.

    Fragen wir mal andersrum, welche Implementation macht das denn so? MSVC 2010 lässt mein Beispiel zu. Dem ollen Borland C++ war die Signatur der main auch egal. gcc warnt soweit ich weiß nur, das kann ich gerade nicht probieren.



  • Bashar schrieb:

    pumuckl schrieb:

    Naja, ich lese das in §3.6.1 so: Es MUSS eine main im Programm geben, die der Einstiegspunkt des Programms ist. main darf nicht überladen werden. Soll heißen, es darf exakt eine Funktion main geben. Diese Funktion ist der Einstiegspunkt. Wenn eine Implementation das vermurkst, ist die Implementation nicht konform.

    Fragen wir mal andersrum, welche Implementation macht das denn so? MSVC 2010 lässt mein Beispiel zu. Dem ollen Borland C++ war die Signatur der main auch egal. gcc warnt soweit ich weiß nur, das kann ich gerade nicht probieren.

    Nein, der GCC erlaubt GAHNix anderes als int und char**. Siehe hier




  • Mod


  • Mod

    2 An implementation shall not predefine the main function. This function shall not be overloaded. It shall have a return type of type int, but otherwise its type is implementation-defined. All implementations shall allow both of the following definitions of main:
    int main() { /* ... / }
    and
    int main(int argc, char
    argv[]) { /* ... */ }
    In the latter form argc shall be the number of arguments passed to the program from the environment in which the program is run. If argc is nonzero these arguments shall be supplied in argv[0] through argv[argc-1] as pointers to the initial characters of null-terminated multibyte strings (ntmbs s) (17.5.2.1.4.2) and argv[0] shall be the pointer to the initial character of a ntmbs that represents the name used to invoke the program or "". The value of argc shall be non-negative. The value of argv[argc] shall be 0. [ Note: It is recommended that any further (optional) parameters be added after argv. —end note ]

    Um also auf die Ursprungsfrage zurückzukommen: Es steht einer Implementation frei, den Code zu akzeptieren oder zurückzuweisen.
    C99 kennt die Kategorien strictly conforming program und conforming program. Auf C++ angewandt, wäre ein Programm mit einer solchen main-Funktion konform, aber nicht streng konform, da für letzteres das Verhalten nicht von der implementation abhängen darf.



  • camper, liest du aus dem Text heraus, dass ein Compiler eine main-Signatur entweder unterstützen oder ablehnen muss?


  • Mod

    Bashar schrieb:

    camper, liest du aus dem Text heraus, dass ein Compiler eine main-Signatur entweder unterstützen oder ablehnen muss?

    Eine (hosted) Implementation muss main unterstützen. Ob und in wieweit zusätzliche Signaturen (außer den beiden vorgegeben) unterstützt werden, ist dagegen durch die Implementation festzulegen (die darf auch festlegen, dass keine zusätzlichen Varianten erlaubt sind - das implementation-defined bezieht sich ja auf alle denkbaren Typen einschließlich der Vorgaben).



  • Bashar schrieb:

    camper, liest du aus dem Text heraus, dass ein Compiler eine main-Signatur entweder unterstützen oder ablehnen muss?

    Ich lese das daraus. Mit Betonung auf unterstützen, d.h. sinnvoll umsetzen. Eine main-Signatur nur zu akzeptieren und Murks zu machen ist nicht standardkonform.


  • Mod

    pumuckl schrieb:

    Bashar schrieb:

    camper, liest du aus dem Text heraus, dass ein Compiler eine main-Signatur entweder unterstützen oder ablehnen muss?

    Ich lese das daraus. Mit Betonung auf unterstützen, d.h. sinnvoll umsetzen. Eine main-Signatur nur zu akzeptieren und Murks zu machen ist nicht standardkonform.

    Ach die Wortwahl war das Probelm... ja, mit akzeptieren ist hier natürlich sinnvoll umsetzen gemeint.
    Die Implementation muss dokumentieren, welche Signaturen unterstützt werden, was bei Verwendung solcher zusätzlichen Signaturen passiert/zu beachten ist, und natürlich auch, was passiert, wenn eine nicht unterstützte Signatur verwendet wird; undefiniertes Verhalten darf nicht auftreten.



  • 314159265358979 schrieb:

    http://ideone.com/XqA5e

    camper schrieb:

    http://ideone.com/KMjEl

    error: second argument of ‘int main(const int&, const char*)’ should be ‘char **’
    

    Ja aber - ja aber - 🤡 Sternchen vergessen 🤡
    http://ideone.com/jOZqH


Anmelden zum Antworten