Semikolon vor else erlaubt, oder nicht?

[Michael G. (glunzl)]

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.

if (bedingung)
  {
    anweisung1 ;
    anweisung2 ; // Hier Semikolon erlaubt
  }
else
  anweisung3 ;

So ist es nicht richtig:

if (bedingung)
  anweisung1 ; // Falsch, hier darf kein Semikolon stehen
else
  anweisung2 ;

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

[Thomas (Gast)]

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 (Gast)]

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:

if (bedingung) {
  anweisung1 ; /* Sauberer ist es auch, in C-Code C-Kommentare zu verwenden */
} else {
  anweisung2 ;
}

[Jörg W. (dl8dtl) (Moderator)]

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.

[Rolf Magnus (Gast)]

>  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.

[Sphinx (Gast)]

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!

[Wolfgang-G (Gast)]

>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

[Karl H. (kbuchegg)]

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 ...

int main()
{
  int i = 5, j;

  if( i == 5 )
    j = 8
  else
    j = 9;
}

... 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.

[Rolf Magnus (Gast)]

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.

[Karl H. (kbuchegg)]

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 :-)

[Alex (Gast)]

"Die //-Kommentare sind seit 8 Jahren Teil von C."

Dann frag ich mich warum man Lint-Tools dort immer meckert ;-)

[Jörg W. (dl8dtl) (Moderator)]

> 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 (Gast)]

>> 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....

[Peter D. (peda)]

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

[Rolf Magnus (Gast)]

> 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.

[Johannes M. (johnny-m)]

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...

[Sphinx (Gast)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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).

[Rolf Magnus (Gast)]

>> 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.