Programm für Parkhaussteuerung
-
volkard schrieb:
Scorcher24 schrieb:
DU weisst ganz genau warum, Mr. Autor :p.
mich stört die vehemenz, mit der die einäugigen den blinden was vorschreiben. "aber nicht void! Niemals nimmer.", als wenn das ein staatsverbrechen wäre.
dieses verhalten sehe ich übrigens nicht nur bei c++, sondern in allen fachbereichen.Ok, wenn ich das zu "stark" rübergebracht habe tut mir das leid.
Aber ich hab das früher auch so geschrieben und zwar ne ziemliche Zeit lang ;). Stand in meinem Buch damals so drin von M&T. Leider ist das immer noch sehr verbreitet :(.
rya.
-
volkard schrieb:
dieses verhalten sehe ich übrigens nicht nur bei c++, sondern in allen fachbereichen.
Das Problem besteht auch darin, dass Anfänger es nicht ernst nehmen, wenn man sagt: "
void main()ist nicht unbedingt so gut, vielleicht wäreint main()besser."Das ist ähnlich wie mit
goto- als Anfänger lässt man lieber ganz die Finger davon, da man es mit grosser Wahrscheinlichkeit falsch einsetzen wird und sich dadurch ein schlechter Codestil herausbildet. Mit der Zeit bildet man sich aber weiter und hört automatisch neue Meinungen. Dazu sollte man auch beginnen, Dinge zu hinterfragen. Strikte Anweisungen sind anfangs oft geeigneter - auch wenn es später dazu berechtigte Ausnahmen geben mag.Hier hingegen kann man auch immer
int main()schreiben, ohne irgendwann etwas zu verpassen. Besser, man tut das von Anfang an, gerade weil es gegenübervoid main()nur Vorteile bietet.
-
volkard schrieb:
mich stört die vehemenz, mit der die einäugigen den blinden was vorschreiben.
der standard schreibt vor, nicht die "einäugigen" (ist das eigentlich zwanghaft bei dir?)
"aber nicht void! Niemals nimmer.", als wenn das ein staatsverbrechen wäre.
im staate c++ ist es ja auch ein verbrechen.
Scorcher24 schrieb:
Ok, wenn ich das zu "stark" rübergebracht habe tut mir das leid.
-
jägertroll schrieb:
"aber nicht void! Niemals nimmer.", als wenn das ein staatsverbrechen wäre.
im staate c++ ist es ja auch ein verbrechen.
nö. lies 3.6.1.2
da stehts ganz deutlich, daß compilerbauer auch andere formen anbieten dürfen.
-
volkard schrieb:
jägertroll schrieb:
"aber nicht void! Niemals nimmer.", als wenn das ein staatsverbrechen wäre.
im staate c++ ist es ja auch ein verbrechen.
nö. lies 3.6.1.2
da stehts ganz deutlich, daß compilerbauer auch andere formen anbieten dürfen.Ja und nein.
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: [blablabla]
Andere Formen sind zusätzlich zulässig, aber sie müssen int zurückgeben.
-
volkard schrieb:
nö. lies 3.6.1.2
da stehts ganz deutlich, daß compilerbauer auch andere formen anbieten dürfen.3.6.1.2 schrieb:
It shall have a return type of type int, but otherwise its type is implementation-defined.
ach, zu spät.
-
7H3 N4C3R schrieb:
Ja und nein.
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: [blablabla]
Andere Formen sind zusätzlich zulässig, aber sie müssen int zurückgeben.
mist. da habe ich das "otherwise" als "anderenfalls" statt als "im übrigen" übersetzt. jetzt bin ich aber verunsichert.
-
volkard schrieb:
7H3 N4C3R schrieb:
Ja und nein.
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: [blablabla]
Andere Formen sind zusätzlich zulässig, aber sie müssen int zurückgeben.
mist. da habe ich das "otherwise" als "anderenfalls" statt als "im übrigen" übersetzt. jetzt bin ich aber verunsichert.
Wie ich das sehe sind das nichtmal die einzigen beiden deutungen..
Irgendwie wiederspricht sich das ganze ja auch. int ist ja ansich schon Implementierungsabhängig. Von dem her erübrigt sich der zweite Teil ja. Wie sollte dann (im Falle von "im übrigen") int sonst noch anders sein? Oder im Falle von "andernfalls" wiederspricht sich das mit dem ersten Teil..So Sachen würde ich gerne die Leute fragen, die das geschrieben haben..
-
drakon schrieb:
Wie sollte dann (im Falle von "im übrigen") int sonst noch anders sein?
Die Rückgabe steht so wohl fest, aber vielleicht ein dritter Parameter, der bei irgendeinem (Phantasie-)OS theoretisch einen Sinn haben könnte?
-
_matze schrieb:
drakon schrieb:
Wie sollte dann (im Falle von "im übrigen") int sonst noch anders sein?
Die Rückgabe steht so wohl fest, aber vielleicht ein dritter Parameter, der bei irgendeinem (Phantasie-)OS theoretisch einen Sinn haben könnte?
Hmm. Ich habe das immer bezogen auf den Rückgabewert gelesen. Mit der Funktionssignatur macht es natürlich mehr Sinn, aber das ist ja eigentlich kein Typ..
Eine Stickwortliste wäre hier wahrscheinlich eher verständlich gewesen.
-
drakon schrieb:
Hmm. Ich habe das immer bezogen auf den Rückgabewert gelesen.
Ja, so hört es sich auch an. Mit "its type" muss eigentlich der Rückgabewert, der Typ der Funktion, gemeint sein. Ich habe nur versucht, in dem Halbsatz irgendeine Logik zu entdecken...
-
_matze schrieb:
drakon schrieb:
Hmm. Ich habe das immer bezogen auf den Rückgabewert gelesen.
Ja, so hört es sich auch an. Mit "its type" muss eigentlich der Rückgabewert, der Typ der Funktion, gemeint sein. Ich habe nur versucht, in dem Halbsatz irgendeine Logik zu entdecken...
Rein grammatikalisch macht es so auch Sinn, aber es passt einfach nicht, weil eine Funktionssignatur kein Typ ist.. Das wäre so ein Moment, wo ich mich frage, wie ein nativer Englischsprecher das sieht.. Wahrscheinlich wird der wirklich schlau draus.
-
drakon schrieb:
Das wäre so ein Moment, wo ich mich frage, wie ein nativer Englischsprecher das sieht.. Wahrscheinlich wird der wirklich schlau draus.
Wir haben einen auf der Arbeit, den frag ich morgen. Wenn der auf Anhieb weiß, wie es gemeint ist, dann fress ich eine Diskette! Und zwar 5 1/4 Zoll!
-
_matze schrieb:
drakon schrieb:
Das wäre so ein Moment, wo ich mich frage, wie ein nativer Englischsprecher das sieht.. Wahrscheinlich wird der wirklich schlau draus.
Wir haben einen auf der Arbeit, den frag ich morgen. Wenn der auf Anhieb weiß, wie es gemeint ist, dann fress ich eine Diskette! Und zwar 5 1/4 Zoll!
Dann will ich aber ein Foto.. :p - oder besser ein Film. Und den packst du dann auf Youtube und wirst weltberühmt!
-
drakon schrieb:
_matze schrieb:
drakon schrieb:
Das wäre so ein Moment, wo ich mich frage, wie ein nativer Englischsprecher das sieht.. Wahrscheinlich wird der wirklich schlau draus.
Wir haben einen auf der Arbeit, den frag ich morgen. Wenn der auf Anhieb weiß, wie es gemeint ist, dann fress ich eine Diskette! Und zwar 5 1/4 Zoll!
Dann will ich aber ein Foto.. :p - oder besser ein Film. Und den packst du dann auf Youtube und wirst weltberühmt!
Klar, kein Problem! Der wird sowieso genauso ratlos sein wie wir...
Außerdem ist eine 5.25" Diskette sicher leichter zu verspeisen als eine 3.5". Die sind so hart und kratzen immer so im Hals...
-
_matze schrieb:
drakon schrieb:
Wie sollte dann (im Falle von "im übrigen") int sonst noch anders sein?
Die Rückgabe steht so wohl fest, aber vielleicht ein dritter Parameter, der bei irgendeinem (Phantasie-)OS theoretisch einen Sinn haben könnte?
ich verstehe es folgendermaßen: eine implementierung könnte z.b.
int main(StartupInfo* bla)anbieten. nicht jedochvoid main(StartupInfo* bla).drakon schrieb:
Ja, so hört es sich auch an. Mit "its type" muss eigentlich der Rückgabewert, der Typ der Funktion, gemeint sein.
"function type" ist die signatur + rückgabetyp.