|
Anzeige
|
Semikolon vor else erlaubt, oder nicht?Hallo! Heute gab es großes gezehter nach einer Klassenarbeit ... C / C++: Darf vor else ein Semikolon stehen? Ich habe gelernt: Nein, es sei denn es steht innerhalb eines Blockes z.B.
So ist es nicht richtig:
Sollte ich richtig liegen, wo kann ich es nachlesen??? Auf dieses Forum verweisen wird den Leherer nicht überzeugen... Gibt es hierbei einen Unterschied zwischen C und C++? Gruß und Dank Michael [EDIT]Komma durch Semikolon ersetzt
Gast
#688429
Wenn du mit Komma ein Semikolon meinst, dann sehe ich das folgenderweise: Ein Semikolon schließt eine Anweisung ab. Folglich muss dies nach jeder Anweisung gesetzt werden. Egal, ob anschließend ein else kommt oder nicht. Man kann das ja auch einfach mal nen Compiler fragen, bei welchen Konstellationen die Warnungen oder Fehler kommen. MfG
Gast
#688431
Beide Beispiele sind (zumindest für C) richtig, wobei es 'sauberer' wäre, Anweisung 1 und 2 im zweiten Beispiel und Anweisung 3 auch in Klammern zu setzen:
Du hast das mit Pascal verwechselt. Bei Pascal ist das Semikolon ein Trennzeichen zwischen Anweisungen. Da nach dem if genau eine Anweisung stehen kann (ggf. halt ein ganzer Block, das ist nach außen syntaktisch auch nur eine Anweisung), darf dort kein Semikolon stehen. Bei C hingegen schließt das Semikolon die Anweisung ab und muss daher auch vor dem else stehen. Das hängt damit zusammen, dass in C die Grenze zwischen Ausdrücken und Anweisungen gegenüber Pascal anders gelegt ist: ein Ausdruck wird durch das abschließende Semikolon zur Anweisung. In Pascal kann ein Ausdruck selbst niemals Anweisung sein.
Gast
#688575
> anweisung1 ; /* Sauberer ist es auch, in C-Code C-Kommentare zu > verwenden */ Die //-Kommentare sind seit 8 Jahren Teil von C. > Bei C hingegen schließt das Semikolon die Anweisung ab und muss daher > auch vor dem else stehen. Die Betonung liegt auf "muss", da der OP ja fragte, ob es dort stehen darf. Es darf nicht nur, sondern muß da stehen.
Gast
#688579
Die Semikolon sind in beiden Beispielen korrekt gesetzt. Nach jeder Anweisung kommt ein Semikolon. if und else Anweisungen sind da erstmal irrelevant. [c] if (bedingung) anweisung1 ; // Hier MUSS ein Semikolon stehen! else anweisung2 ; [\c] Das einfachste ist, wenn Du sowas einfach mal compilierst und guckst was passiert. Ein Grundlagenbuch über C könnte allerdings auch nicht schaden ;) Gruss!
Gast
#688788
>Das einfachste ist, wenn Du sowas einfach mal compilierst und guckst was >passiert. nein. für eine Klassenarbeit sollte probieren der falsche Weg sein für Hobbyprogrammierer ja Wolfgang-G wrote: >>Das einfachste ist, wenn Du sowas einfach mal compilierst und guckst was >>passiert. > nein. für eine Klassenarbeit sollte probieren der falsche Weg sein Na ja. Wenn die These lautet, dass ...
... korrektes C ist, dann kann man in 20 Sekunden ausprobieren herausfinden, ob die These stimmen kann oder ob sie komplett falsch ist. Da der Compiler hier einen Fehler schmeissen wird, wird die These wohl nicht zu halten sein. Zeitbedarf mit Compilerunterstützung: vielleicht 30 Sekunden bis 1 Minute. Das erklärt zwar nicht warum das so ist, vermeidet aber eine sinnlose Diskussion mit dem Lehrer ob man nun recht hat oder nicht. Denn nichts ist peinlicher als eine Diskussion mit dem Lehrer, der dann genau obigen konkreten Test macht und auf die Fehlermeldung verweist.
Gast
#688986
Das stimmt zwar, aber einen Compiler sollte man eben nicht als normativ ansehen. Nur weil in einem bestimmten Compiler ein Konstrukt funktioniert, heißt das nicht, daß das Standard-C ist. Rolf Magnus wrote:
> funktioniert, heißt das nicht, daß das Standard-C ist.
Da geb ich dir durchaus recht.
Allerdings bin ich der Überzeugung, dass auch der grindigste
C Compiler noch immer mehr von C-Syntax versteht als 99%
aller Informatik-Lehrer da draussen :-)
Wenn der Compiler keinen Fehler meldet, heist das noch lange
nicht, dass es Standard-C ist.
Wenn aber der Compiler einen Fehler meldet, stehen die
Chancen nicht schlecht, dass das Konstrukt auch nach ANSI-C
Regeln tatsächlich fehlerhaft ist.
Und wie heist es so schön: Der Compiler hat immer recht,
vor allen Dingen deshalb, weil du sowieso nichts dagegen
tun kannst :-)
Gast
#689234
"Die //-Kommentare sind seit 8 Jahren Teil von C." Dann frag ich mich warum man Lint-Tools dort immer meckert ;-) > Dann frag ich mich warum man Lint-Tools dort immer meckert ;-)
Vielleicht fragst du ja besser dein lint bzw. dessen Hersteller?
Aber welcher lint ist eigentlich wirklich hinreichend auf der Höhe
der Zeit bezüglich aller C99-Features?
Gast
#689497
>> Dann frag ich mich warum man Lint-Tools dort immer meckert ;-) > >Vielleicht fragst du ja besser dein lint bzw. dessen Hersteller? > >Aber welcher lint ist eigentlich wirklich hinreichend auf der Höhe >der Zeit bezüglich aller C99-Features? Da hast Du Recht - wir setzen QA-C in der aktuellsten Version ein - es stützt sich aber trotzdem nur aus ISO C90 und meckert deswegen über C++ Kommentare im C-Code.... Seit ich einmal tierisch auf /* */ reingefallen bin, setze ich es überhaupt nicht mehr ein. Wer denkt sich denn auch sowas blödes aus, daß Kommentare keine Kommentare beinhalten dürfen. Ich benutze // für Zeilenkommentare und #if 0, #endif für mehrzeilige Auskommentierungen. Damit kann ich nie mehr in die Schachtelungsfalle reinfallen. Peter
Gast
#689507
> Wer denkt sich denn auch sowas blödes aus, daß Kommentare keine > Kommentare beinhalten dürfen. Wozu bräuchte man denn sowas? > Ich benutze // für Zeilenkommentare und #if 0, #endif für mehrzeilige > Auskommentierungen. Ich benutze // für Kommentare am Zeilenende oder zum Auskommentieren einzelner Zeilen, /* und */ für mehrzeilige Kommentare und #if 0 und #endif für mehrzeiliges "Auskommentieren". > Damit kann ich nie mehr in die Schachtelungsfalle reinfallen. Von wo bis wo ein Kommentar geht, sieht man doch sowieso durch's Syntax-Highlighting im Editor. Rolf Magnus wrote: >> Wer denkt sich denn auch sowas blödes aus, daß Kommentare keine >> Kommentare beinhalten dürfen. > > Wozu bräuchte man denn sowas? Z.B. dann, wenn man einen längeren Code-Abschnitt inklusive der dazugehörigen Kommentare auskommentieren will...
Gast
#689514
Also wenn ich an meinen Informatiklehrer zurückdenke, kriege ich das kalte Grausen. Daher mein Vorschlag mit dem C Compiler! Mein Informatiklehrer hat uns sonstwas vom Himmel erzählt... Da half kein diskutieren sondern nur der Gegenbeweis. Johannes M. wrote: > Z.B. dann, wenn man einen längeren Code-Abschnitt inklusive der > dazugehörigen Kommentare auskommentieren will... Dafür ist #if 0 deutlich praktikabler (und eine Sache, die bei Pascal für ebendiesen Zweck komplett gefehlt hat).
Gast
#689932
>> Wozu bräuchte man denn sowas? > Z.B. dann, wenn man einen längeren Code-Abschnitt inklusive der > dazugehörigen Kommentare auskommentieren will... Deshalb benutzt man dazu ja auch #if 0 und #endif. Das hilft auch dem Syntaxhighlighter, zwischen Kommentaren und ausgeklammertem Code zu unterscheiden. Antwort schreiben |
Anzeige
|
