www.mikrocontroller.net

Forum: Compiler & IDEs Semikolon vor else erlaubt, oder nicht?


Autor: Michael Glunz (glunzl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;
}

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>  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.

Autor: Sphinx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Wolfgang-G (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Die //-Kommentare sind seit 8 Jahren Teil von C."

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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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....

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Sphinx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.