malloc Allozierung geht verloren

Athar schrieb:

Ja, das ganze kompiliert nämlich nicht.

Bei mir schon.

Und ja, es kann was kaputt gehen! Die Gatter können durchbrennen

wxSkip

Seriously schrieb:

Athar schrieb:

Ja, das ganze kompiliert nämlich nicht.

Bei mir schon.

Und ja, es kann was kaputt gehen! Die Gatter können durchbrennen

Das einzige, was hier kaputt geht, ist die Geduld der Forumsteilnehmer

Michael E.

unskilled schrieb:

Sinn machen kann es so und so nicht - wenn überhaupt kann es Sinn ergeben

Blödsinn. Seit ich von Lessing (18. Jahrhundert) diese Formulierung gesehen habe, glaube ich nicht mehr an das Märchen vom neuen bösen Anglizismus.

Wie dem auch sei, im C++-Standard ist explizit festgehalten, dass main einen int zurückgeben muss.

ISO/IEC 14882:2003 3.6.1 (2) schrieb:

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[]) { /* ... */ }
(... es folgt eine Beschreibung von argc und argv ...)

Von Rechts wegen darf ein C++-Compiler "void main" nicht akzeptieren.

volkard

seldon schrieb:

Wie dem auch sei, im C++-Standard ist explizit festgehalten, dass main einen int zurückgeben muss.

ISO/IEC 14882:2003 3.6.1 (2) schrieb:
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[]) { /* ... */ }
(... es folgt eine Beschreibung von argc und argv ...)
Von Rechts wegen darf ein C++-Compiler "void main" nicht akzeptieren.

Ich kann nicht so gut Englisch. aber sagt "but otherwise its type is implementation-defined" nicht genau das Gegenteil, also daß sehr wohl anderes gemacht werden darf, aber dann die Sache halt implementation-defined wird?
Also kein absolutes void-Verbot mehr und kein Kreuzzug und keine Heilige Inquisition, wenn das jemand geschrieben hat?

Frage: Warum in C++ malloc und nicht new?

Zu

int main() { /* ... */ }

ist das ja in einigen Compilern so umgesetzt, das das normalerweise folgende:

return

entfallen kann, da der Compiler in dem Fall weiss was er machen sollte.

Dann steht alle Implementationen sollten folgendem Muster folgen:

int main() { /* ... */ }

So weit meine recht freie Interpretation

Wie schrieb Volkard: Komma können Leben retten

MfG f.-th.

Okay Satzzeichen und eventuelle Missinterpretationen

Mit "in dem Fall" ist gemeint, wenn nicht ein anderer Rückgabewert des Programms von der Umgebung gefordert ist.

Hoffe nun sind alle Klarheiten beseitigt

Nukularfüsiker

volkard schrieb:

Ich kann nicht so gut Englisch. aber sagt "but otherwise its type is implementation-defined" nicht genau das Gegenteil, also daß sehr wohl anderes gemacht werden darf, aber dann die Sache halt implementation-defined wird?

Bin auch kein Englisch-Master, aber meiner Auffassung nach steht da, dass die main-Funktion int zurückgeben muss, aber darüber hinaus ihr Typ von einer konkreten Implementation vorgegeben werden kann. Das ist die Lesart für "shall", die bei technischen Spezifikationen wie z. B. RFCs gilt.

[was hier stand war Unsinn und steht deshalb jetzt nicht mehr hier]

Also kein absolutes void-Verbot mehr und kein Kreuzzug und keine Heilige Inquisition, wenn das jemand geschrieben hat?

Statt dessen Folterung und langsamer Tod.

"but otherwise" == "aber ansonsten".

Das heißt, main muss int zurückgeben, aber welche Parameter sie entgegennehmen kann, ist implementationsabhängig - es müssen halt nur mindestens die beiden angegebenen unterstützt werden.

Beispielsweise findet man häufig die dritte Form

int main(int argc, char *argv[], char *envp[]);

in der ein Array von Umgebungsvariablen als envp mitgegeben wird.

Nexus

volkard schrieb:

ISO/IEC 14882:2003 3.6.1 (2) schrieb:

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.

Ich kann nicht so gut Englisch. aber sagt "but otherwise its type is implementation-defined" nicht genau das Gegenteil, also daß sehr wohl anderes gemacht werden darf, aber dann die Sache halt implementation-defined wird?

Ich verstehe den Satz so, dass sich "its type" auf den Typ der Funktion bezieht, also bezeichnet "otherwise its type" den Funktionstyp ohne Rückgabetyp, was den Parametern entspricht.

volkard

Ja, klingt logisch.
Aber die hätten ruhig netter sein können und statt zu schreiben
"Der Rückgabetyp muß int sein, aber ansonsten ist der Typ durch die Implementierung definiert."
lieber
"Der Rückgabetyp muß int sein und die Parameter sind durch die Implementierung definiert."
So lerne ich nie C++.

drakon

Die Stelle ist wirklich sehr ungeschickt forumuliert. Da hätten 2 getrennte Sätze einiges an Konfusion vermeiden können.

Ich fand die Formulierung eigentlich ziemlich klar und eindeutig - der Typ einer Funktion ist halt ihre Signatur, und der Standard schränkt diesen für main so ein, dass int als Rückgabetyp verlangt wird.

Um ehrlich zu sein, ich bin über eure Verwirrung ziemlich verwirrt.

drakon

seldon schrieb:

Ich fand die Formulierung eigentlich ziemlich klar und eindeutig - der Typ einer Funktion ist halt ihre Signatur, und der Standard schränkt diesen für main so ein, dass int als Rückgabetyp verlangt wird.

Um ehrlich zu sein, ich bin über eure Verwirrung ziemlich verwirrt.

Es ist imo nicht ganz klar, worauf sich das "its" dort bezieht. Wenn man das das erste mal liest, dann kann man das schon so verstehen, dass es sich auf "return type" bezieht.