Hallo Leute, mir hat mal ein Kollege in meiner alten Firma ein "hello world"-Programm gezeigt, dass ohne ; auskam. Leider find ich die Mail nicht mehr. Kann mir von Euch da einer weiter helfen? Mein neuer Kollege will mir einfach nicht glauben, dass das mit der normalen C-Syntax funktioniert. Danke schonmal.
So:
1 | #include <stdio.h> |
2 | |
3 | void main() { |
4 | if (printf("Hello World")) { |
5 | }
|
6 | }
|
;) printf ist schließlich eine normale Funktion... sie gibt als Wert die Anzahl der geschriebenen Zeichen zurück.
Ist aber kein Standardkonformes C-Programm, weil der Return-Typ von main() nicht int ist.
Rolf Magnus schrieb: > Ist aber kein Standardkonformes C-Programm, weil der Return-Typ von > > main() nicht int ist.Beitrag melden | Bearbeiten | Löschen |
1 | #include <stdio.h> |
2 | |
3 | int main() { |
4 | if (printf("Hello World")) { |
5 | }
|
6 | }
|
Es fehlt nicht. Man darf es hier weglassen. Das entspricht dann einem return 0. Das ist eine spezielle Ausnahme, die nur für main() gilt. Ich hab nie verstanden, wozu diese spezielle Ausnahme gut sein soll, aber jetzt weiß ich es: Damit man ein C-Programm ohne Semikolon schreiben kann ;-)
Rolf Magnus schrieb:
> Es fehlt nicht.
gcc main.c -o main.exe -Wall
main.c: In function `main':
main.c:6: warning: control reaches end of non-void function
Naja dürfen darf man schon, aber ob das sauberes Programmieren ist...
;-) Den kannte ich nocht nicht. Hello world ohne Semikolon ... , tse, tse.
Mark Brandis schrieb: > gcc main.c -o main.exe -Wall > main.c: In function `main': > main.c:6: warning: control reaches end of non-void function Probier's mal mit: gcc main.c -o main.exe -Wall -std=c99 > Naja dürfen darf man schon, aber ob das sauberes Programmieren ist... In ISO-C ist exakt definiert, was dann passiert. Aber du darfst gerne eine Lösung vorstellen, die das return enthält, wenn du kannst ;-)
Einen direkten Weg zum Festlegen des Returnwertes habe ich nicht gefunden, indirekt geht das aber.
1 | #include <stdio.h> |
2 | |
3 | int main() { |
4 | if (printf("Hello world\n")) { |
5 | }
|
6 | if (getchar() == 'A') { |
7 | if (printf("")) { //returns 0 |
8 | }
|
9 | } else { |
10 | if (printf("\r")) { //returns 1 |
11 | }
|
12 | }
|
13 | }
|
Danach echo $? auf der Konsole eingeben.
Malte __ schrieb: > Einen direkten Weg zum Festlegen des Returnwertes habe ich nicht > gefunden, indirekt geht das aber. So, aber nicht, denke ich. Wo im Code "returns" steht wird der Rückgabewert zum Ergebnis der Auswertung der Bedingung. Mit dem vom "return" Befehl "zurückgegebenen" Ergebniswert des Programms hat das nichts zu tun.
Naja, wenn der Compiler den Code so erzeugt, daß eine int-Funktion immer in einem bestimmten Register ihren Wert zurückgibt, dann steht der Rückgabewert von printf in eben diesem. Wenn man in main() kein return hat, steht der Wert von printf da immer noch drin und letztlich liefert main dann den letzten Rückgabewert von printf. Portables Programmieren sieht freilich anders aus.
Liest eigentlich keiner, was ich schreibe? In ISO-C ist genauestens definiert, was passiert, wenn main() ohne return-Anweisung verlassen wird: Es wird 0 zurückgegeben. Egal, was printf für einen Returnwert hatte. PS: Es kann sein, daß man dazu dem gcc mit -std=c99 sagen muß, daß er den Code nicht auf Basis einer seit 11 Jahren veralteten Version von C übersetzen soll.
Gelesen habe ich es wohl ... :-) Du magst ja auch Recht haben. In C++ und (das wusste ich bisher nicht, aber mag gut sein) ISO-C99 ist kein return so gut wie return 0. Aber nur zur Sicherheit: In K&R-C und dem doch noch recht gängigen ANSI-C ist es eben nicht so. MS Visual C++ z.B. ist i.W. ANSI-C und hat mit ISO-C99 nicht viel am Hut.
Klaus Wachtler schrieb: > Aber nur zur Sicherheit: In K&R-C und dem doch noch recht gängigen > ANSI-C ist es eben nicht so. Das stimmt. Diese C-Varianten sind allerdings schon seit so langer Zeit veraltet, daß ich die nicht weiter in Betracht ziehe. Sie sind für mich Geschichte. > MS Visual C++ z.B. ist i.W. ANSI-C und hat mit ISO-C99 nicht > viel am Hut. Eigentlich blöd, denn C89/C90 hat mit Erscheinen von C99 seine Gültigkeit verloren. Man kann die Definition seither auch nicht mehr von offizieller Stelle kaufen. Meiner Meinung nach taugt ein C-Compiler nix, wenn er nach 11(!) Jahren C99 immer noch nicht wenigstens einigermaßen implementiert hat.
Klaus Wachtler schrieb: > MS Visual C++ z.B. ist i.W. ANSI-C und hat mit ISO-C99 nicht > viel am Hut. welche Version? Ich habe es gerade mit der 2003 getestet und da kommt keine Warnung oder ein Fehler.
Rolf Magnus schrieb: > Es kann sein, daß man dazu dem gcc mit -std=c99 sagen muß, daß er > den Code nicht auf Basis einer seit 11 Jahren veralteten Version von C > übersetzen soll. Ja, muss man. Default ist -std=gnu89. Dafür gibt's dort aber dann auch eine Warnung: foo.c:7: warning: control reaches end of non-void function Die gibt es mit -std=c99 oder -std=gnu99 nicht.
Peter schrieb: > Klaus Wachtler schrieb: >> MS Visual C++ z.B. ist i.W. ANSI-C und hat mit ISO-C99 nicht >> viel am Hut. > > welche Version? > Ich habe es gerade mit der 2003 getestet und da kommt keine Warnung oder > ein Fehler. Du hast was getestet? Wenn wegen des fehlenden return kein Fehler kommt, heißt das noch lange nicht, daß VC++ nennenswert C99-konform wäre. Mein letzter Stand dazu ist VS2005; das ist von C99 meilenweit entfernt. Meines Wissens hat sich seither in diesem Punkt nicht viel getan, ich lasse mich aber auch gern eines besseren belehren. Jedenfalls ist es so, daß dank VC++ leider nicht C99 als komplett eingeführt betrachtet werden kann - auch wenn es anders sein sollte. Ein Erlebnis der anderen Art war mal ein Programm, das woanders entstand und eigentlich für ISO-C99 gedacht war. Wenn ein Compiler dann sowas wie isnan() nicht kennt, meckert er halt und man mogelt sich drum rum. Dann verhielt sich das Ding aber recht schrullig. Mit etwas Suche kam dann raus, daß NAN (lt. C99 ein Wert einer ungültigen FP-Zahl) im Quelltext verwendet wird, der Compiler sich nicht dran stört (weil es zufällig in irgendeiner Headerdatei definiert war, ich glaube xwindows.h o.s.ä.), nur leider nicht im Sinne einer "not a number" sondern mit dem Wert 2. Genau: #define NAN 2... Soviel zum Thema MS und Konformität.
Hmm, das gibt mir irgendwie zu denken. Einerseits hat Microsoft jemanden, der im Komitee sitzt und an neuen Versionen der Norm mitarbeitet, andererseits haben sie keinerlei Interesse, das dort beschlossene dann auch in ihren Compiler zu integrieren, wenn nicht irgendwelche Benutzer explizit danach fragen. Was um alles in der Welt haben die dann im Komitee verloren?
Rolf Magnus schrieb: > Was um alles in der Welt > haben die dann im Komitee verloren? Wenig. Dass die Namen der beiden Funktionen in snprintf() (ISO-C) und _snprintf() (Microsoft) zum Verwechseln ähnlich sind, obwohl _snprintf() sich nicht wie snprintf() verhält (und sich auch gar nicht so verahlten soll), ist sicherlich auch rein zufällig.
Rolf Magnus schrieb: > Was um alles in der Welt > haben die dann im Komitee verloren? Bremsen. Im Ernst: Seit sich MS den Mike Suttner eingekauft hat (ein geachtetes Member des C++ Komitees) ist es mit ihrem C++ Compiler stark bergauf gegangen. Ich kann nur hoffen, dass es in C auch so sein wird, dass man irgendwann wieder auf die Anlassprogrammierung verzichtet und die Dinge von Grund auf korrigiert. MS versucht halt momentan die ganze Welt auf C# und .Net zu ziehen. C Programmierung ist unter Windows sowieso eine Qual und den C++ Zug macht man nur deswegen noch mit, weil es da draussen genug Rebellen gibt, die C#, Managed-C++ oder VB einfach verweigern. Und das kann sich eine Firma wie MS dann doch nicht leisten, auf diese Leute zu verzichten. Das kleine Grüppchen der Leute, die mit C an Windows rangehen, ist, so denke ich, für MS hingegen verschmerzbar.
Hallo, du vergisst die Leute die Hardware nah programmieren (Treiber & Co.). Da geht mit .net bekanntlich gar nichts. Das hat nicht mit Verweigerung zu tun, sondern mit einer technischen Notwendigkeit und hauptsächlich dafür werden die C(++) Compiler weiterhin entwickelt. Und unterschätze C nicht. Hier an der FH wird ziemlich laut auf C++ geschimpft. In C++ programmiert hier kaum mehr jemand. Die GUI-Sachen werden in C# oder Java gemacht, die Hardware nahen Dinge in reinem C.
> Hier an der FH wird ziemlich laut auf C++ > geschimpft. In C++ programmiert hier kaum mehr jemand Jaja, hab auch mal an ner FH gearbeitet, dort haben auch alle aus der Abteilung Elektrotechnik auf C++ geschimpft. Langsam, gross, nicht geeignet für Micros usw. usf. Hast du echt mit den Leuten geredet so hat sich dann normalerweise rausgestellt dass für die C++ wie C ist, nur "mit Klassen" und cout anstatt printf.
Achja...mein gcc kompiliert folgendes mit -std=c89 -Wall ohne zu meckern:
1 | #include <stdlib.h> |
2 | #include <stdio.h> |
3 | |
4 | int main() |
5 | {
|
6 | if (printf("hello, world\n")) {}
|
7 | if (exit(23), 42) {}
|
8 | } |
Vorteile: * Keins dieser verdammten Semikolons * Rückgabewert definiert (23)
Hier ist der Prototyp von exit, der's möglich macht:
1 | _VOID _EXFUN(exit,(int __status) _ATTRIBUTE ((noreturn))); |
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.