switch-case Anweisung

peter schrieb:

> Was ist der Endwert von a  ? Springt die Funktion nicht sofort zu
> default, weil case 100 nicht vorhanden ist?

Ja natürlich.
Wenn a den Wert 100 hat, dann ist der erwartete Wert 114.
Das ist in dem Fall sogar unabhängig davon, wie der Compiler die ihm 
überlassene Entscheidung ob ein simpler char ein Vorzeichen haben soll 
oder nicht bewertet.

peter schrieb:
> Danke Karl-Heinz,
>
> der Meinung war ich auch, allerdings wird mir angezeigt, 114 sei eine
> falsche Antwort.

Dann zeig dein komplettes Programm.
Es soll auch schon vorgekommen sein, dass man in diversen Auswertungen 
und Ausgaben einen Fehler hat.

Was kommt denn beim printf raus?

peter schrieb:
> Hallo Karl-Heinz,
>
> ein komplettes Programm gibt es nicht, das ist das einzige was ich habe.

Das ergibt allerdings keinen Sinn. Sieht man daran, dass der von Dir 
gepostete Code nur eine öffnende geschweifte Klammer enthält, aber zwei 
schließende.

Ich denke x ist 0, ++x ist kein postincrement, (-2+1)%2 ergibt -1, -1 
ist wahr,die schleife wird erneut durchlaufen und (-1+1)%2 ist 0, 
ausgabe ist 0.

peter schrieb:
> Danke Karl-Heinz,
>
> der Meinung war ich auch, allerdings wird mir angezeigt, 114 sei eine
> falsche Antwort.

Wer sagt das?

Ein minimal lauffähiges Programm:

1

#include <stdio.h>

2

3

int main()

4

{

5

    char a = 100;

6

    switch (a)

7

    {

8

        case 1:

9

        case 2:

10

           a += 17;

11

        case 10:

12

        case 11:

13

           a -= 36;

14

        default:

15

           a += 14;

16

    }

17

    printf("%d", a);

18

19

    return 0;

20

}

ergibt genau das Ergebnis wie von Karl Heinz genannt:

1

D:\Dateien\C\switch_case>gcc -Wall switch_case.c -o switch_case.exe

2

3

D:\Dateien\C\switch_case>switch_case.exe

4

114

Daniel A. schrieb:
> Ich denke x ist 0, ++x ist kein postincrement, (-2+1)%2 ergibt -1, -1
> ist wahr,die schleife wird erneut durchlaufen und (-1+1)%2 ist 0,
> ausgabe ist 0.

Exakt.

1

#include <stdio.h>

2

3

int x = -2;

4

5

void main(){

6

7

schleife:

8

if (++x % 2)

9

goto schleife;

10

11

printf("%i", x);

12

}

Ausgabe:

1

D:\Dateien\C\schleife>gcc -Wall schleife.c -o schleife.exe

2

schleife.c:5:6: warning: return type of 'main' is not 'int' [-Wmain]

3

 void main(){

4

      ^

5

6

D:\Dateien\C\schleife>schleife.exe

7

0

Mark B. schrieb:
> Wer sagt das?

peter schrieb:
> im Bewertungsbogen steht allerdings, dies sei falsch,

Justus S. schrieb:
> Mark B. schrieb:
>> Wer sagt das?
>
> peter schrieb:
>> im Bewertungsbogen steht allerdings, dies sei falsch,

Dann irrt sich der Bewertungsbogen. Oder aber der Themenersteller postet 
nicht den ganzen Code, oder hat beim Abtippen Fehler eingebaut.

Loog schrieb:
> Für solche "Probleme" kann man schnell den Quelltext online testen

Mich würde es gar nicht wundern, wenn die Leute diesen Quelltext in 
verschiedene Kompiler einfügen und vollkommen unterschiedliche 
Ergebnisse bekommen. Darüber hinaus ist es auch möglich, daß die Antwort 
auf dem Lösungsbogen falsch ist. Ich habe das bei 
Facharbeiter-Prüfungsbögen zum Energieelektroniker erlebt und die IHK 
hat 2 Jahre gebraucht, um das zu berichtigen.
:-(

MfG Paul

Paul B. schrieb:
> Darüber hinaus ist es auch möglich, daß die Antwort
> auf dem Lösungsbogen falsch ist.

selbst in gedruckten und verkauften, verteilten Berufsschulbücher zur 
RFS Ausbildung waren Fehler eingebaut die zur mehrdeutigen Lösung 
führten.

xXx schrieb:
> peter schrieb:
>
>> if (++x % 2)
>
> Ich programmiere seit ueber 20 Jahren in C & C++ und ich bin stolz
> darauf, dass ich diese Frage nicht beantworten kann.

Ist auch kein guter Programmierstil, so wie es dasteht.

xXx schrieb:

> Wo habe ich geschrieben, es waere nicht eindeutig? Ich habe mich nur vor
> vielen Jahren von elitaerem Code ab- und leicht lesbarem Code
> zugewandt.

Wobei 'leicht lesbar' immer im Auge des Betrachters liegt.

> Damit beeindruckt man seine durchschnittlichen Kollegen zwar
> kurzfristig weniger, aber langfristig ist es besser fuer Produktivitaet
> und fuer's Klima, wenn man sich und seinen Kollegen die Arbeit einfacher
> macht.

Und genau das ist auch der Weg vom Amateur zum Profi. Amateure glauben 
immer, man müsse in C möglichst kryptisch programmieren; möglichst viel 
in eine Zeile quetschen; möglichst undurchschaubare Sonderzeichenorgien 
kreieren um bei den Profis anerkannt zu werden. Ein Profi hat längst 
gelernt, dass genau das der sichere Weg ins Desaster ist. Wer ein und 
denselben Source Code 5 Jahre oder noch länger in der Wartung hat, der 
ist darauf angewiesen die Dinge schnell wieder neu erfassen zu können.
Was natürlich nicht heisst, dass man hilflos daneben stehen darf, wenn 
einem solche Dinge unterkommen. Klar kann man das alles auflösen. Und 
dann so umschreiben, dass man beim nächsten mal nicht wieder in dieselbe 
Verlegenheit kommt :-) Denn das nächste mal kommt bestimmt.

xXx schrieb:
> Ich habe mich nur vor vielen Jahren von elitaerem Code ab- und leicht
> lesbarem Code zugewandt.

Was ist daran "elitär"? Spricht hier der Anti-C-Troll?

Rufus Τ. F. schrieb:
> xXx schrieb:
>> Ich habe mich nur vor vielen Jahren von elitaerem Code ab- und leicht
>> lesbarem Code zugewandt.
>
> Was ist daran "elitär"? Spricht hier der Anti-C-Troll?

Niemand wird ernsthaft behaupten wollen, dass das Inkrementieren einer 
Variablen innerhalb einer if-clause sinnvollen und guten Code darstellt.

xXx schrieb:
>> if (++x % 2)

Das Increment muß man nicht notwendig im Vergleich machen.
Ganz anders sieht es schon hier aus:

1

  if (x && (++x % 2))

Da ist die Lesbarkeit besser als mit ner Kette von ifs.

Mark B. schrieb:
> Niemand wird ernsthaft behaupten wollen, dass das Inkrementieren einer
> Variablen innerhalb einer if-clause sinnvollen und guten Code darstellt.

wie macht man das sinnvoller und gut?

wenn ich schon vor der if ein inc brauche nutze ich das, klar kann ich 
vorher inc machen oder sogar eine neue Zeile einsetzen.

Das inc davorzusetzen oder eine neue Zeile davor zu schreiben, macht es 
das besser?
Mir wir dann immer der Moni zu kurz, sei es in Spaltenbreite oder in 
Zeilenlänge was ist daran nun besser?

Peter D. schrieb:
> xXx schrieb:
>>> if (++x % 2)
>
> Das Increment muß man nicht notwendig im Vergleich machen.
> Ganz anders sieht es schon hier aus:
>

1

>   if (x && (++x % 2))

2

>

> Da ist die Lesbarkeit besser als mit ner Kette von ifs.

Da bin ich anderer Meinung.

In eine if-Anweisung gehört ein Vergleich bzw. mehrere Vergleiche. 
Vergleiche sind boolscher Natur bezüglich des Ergebnisses, das sie 
produzieren. Also solche Operationen wie:

größer als
kleiner als
gleich
ungleich

etc.

sowie zur Verknüpfung mehrerer Vergleiche Operatoren wie logisches UND 
und ODER. Arithmetische Operationen gehören dort nicht hin. Also auch 
kein Inkrement, keine Division oder dergleichen.

Der Vorteil davon ist bessere Lesbarkeit und bessere Testbarkeit des 
Codes.

Joachim B. schrieb:
> wie macht man das sinnvoller und gut?
>
> wenn ich schon vor der if ein inc brauche nutze ich das, klar kann ich
> vorher inc machen oder sogar eine neue Zeile einsetzen.
>
> Das inc davorzusetzen oder eine neue Zeile davor zu schreiben, macht es
> das besser?
> Mir wir dann immer der Moni zu kurz, sei es in Spaltenbreite oder in
> Zeilenlänge was ist daran nun besser?

Code richtet sich immer nach der Anforderung, die er erfüllen soll.

Was genau wollte man hier implementieren?

Der Andere schrieb:
> Wann wird das x incrementiert?

&& ist ein sequence point.
Die linke Seite muß zuerst ausgerechnet werden und hat keine 
Seiteneffekte auf die rechte Seite.
Ergibt die linke Seite 0, darf die rechte Seite nicht mehr ausgeführt 
werden.
Das && wird deshalb gerne genommen als Guard gegen ungültige Startwerte.

xXx schrieb:
> Wenn ich Code schreibe, der von 80% meiner Kollegen nicht auf Anhieb
> verstanden werden kann, dann ist das elitaer.

Wenn Deine Kollegen nicht in C programmieren können, ist das nicht 
"elitär".  Und wenn sie in C programmieren können, aber solche 
Codestellen nicht auf Anhieb verstehen -- wer um alles in der Welt hat 
die eingestellt? Und wofür?

Rufus Τ. F. schrieb:
> xXx schrieb:
>> Wenn ich Code schreibe, der von 80% meiner Kollegen nicht auf Anhieb
>> verstanden werden kann, dann ist das elitaer.
>
> Wenn Deine Kollegen nicht in C programmieren können, ist das nicht
> "elitär".  Und wenn sie in C programmieren können, aber solche
> Codestellen nicht auf Anhieb verstehen -- wer um alles in der Welt hat
> die eingestellt? Und wofür?

In einer Firma kann nicht jeder so entwickeln, wie es ihm persönlich 
gerade in den Kram passt. Das kann man zuhause privat gerne machen, aber 
nicht wenn man dafür bezahlt wird.

Wenn man Softwareentwicklung ernsthaft betreibt, dann gibt es 
Programmierrichtlinien an die man sich zu halten hat. Wer das nicht 
will, der kann sich gerne beim IOCCC austoben, dafür ist er da.

Und selbst der hat manche Regeln. ;-)

Was ist wahrscheinlicher:
1.) Dass einer genial ist und supertollen Code schreibt und alle anderen 
zu doof sind um ihm zu verstehen?
2.) Dass jemand die eigenen Fähigkeiten im Programmieren überschätzt und 
in Wahrheit Code verzapft, der unnötig schwer zu lesen und zu warten 
ist?

Im realen Berufsleben habe ich 2.) viel öfter erlebt als 1.). Sehr, 
sehr, sehr, sehr, sehr viel öfter.

Das ist ja alles schön und gut, und sicherlich auch richtig.

Aber bei einem so banalen Konstrukt?

Nein. Wer daran scheitert, dem helfen auch keine Programmierrichtlinien.

Ich meine damit nicht, daß man derartige Konstrukte nutzen muss oder 
auch nur sollte, aber man muss sie verstehen können. Und zwar ohne 
länger darüber nachzudenken.

Paul B. schrieb:
> Darüber hinaus ist es auch möglich, daß die Antwort auf dem Lösungsbogen
> falsch ist.

Ja. Ich kann mich aus meinem Studium auch noch daran erinnern, daß der 
Professor das ANSI-C, das er gelehrt hat, offenbar schlechter kannte als 
ich. In den Prüfungen waren da gerne mal Fragen nach dem Ergebnis eines 
bestimmten Stücks Code enthalten, das eigentlich undefiniertes Verhalten 
und damit kein eindeutiges Ergebnis hat. Und nein, "undefiniert" wurde 
nicht als korrekt gewertet, sondern nur das Ergebnis, das der Compiler, 
den der Prof normalerweise benutzt, produziert.

Mark B. schrieb:
> Code richtet sich immer nach der Anforderung, die er erfüllen soll.

Richtig. Deshalb verwehre ich mich auch gegen so pauschale Sachen wie:

Mark B. schrieb:
> In eine if-Anweisung gehört ein Vergleich bzw. mehrere Vergleiche.
> Vergleiche sind boolscher Natur bezüglich des Ergebnisses, das sie
> produzieren.
[...]
> Der Vorteil davon ist bessere Lesbarkeit und bessere Testbarkeit des
> Codes.

Was besser lesbar ist, hängt nicht nur von dieser einen Zeile ab. Solche 
pauschalen Regeln sind für den Anfänger sicher als Orientierung gut, und 
in den meisten Fällen passen sie ja auch. Aber der Profi erkennt die 
(wenigen) Stellen, an denen er die Lesbarkeit verbessern kann, wenn er 
mal davon abweicht, ohne dass der Code dadurch "elitär" wird (ja, auch 
goto kann sinnvoll sein und die Lesbarkeit verbessern).
Man muss ja nicht gleich hochkomplexe Ausdrücke hinschreiben, bei denen 
man sämtliche Regeln der integer promotion, operator precedence und wer 
weiß was noch alles auswenig kennen muss. Auf der anderen Seite erwarte 
ich von einem professionellen Programmierer aber auch, dass er nicht 
gleich verzweifelt, nur weil ein Konstrukt mal eine Stufe komplizierter 
ist als der Trivialfall. Schließlich kriegt auch der Geld dafür.

> Was ist wahrscheinlicher:
> 1.) Dass einer genial ist und supertollen Code schreibt und alle anderen
> zu doof sind um ihm zu verstehen?

Einstein galt als schlechter Professor, weil seine Studenten seine 
Vorlesungen nicht verstanden haben. ;-)

> 2.) Dass jemand die eigenen Fähigkeiten im Programmieren überschätzt und
> in Wahrheit Code verzapft, der unnötig schwer zu lesen und zu warten
> ist?

Kann auch eine Mischung aus beidem sein. Er ist ein genialer 
Programmierer, der aber leider seinen Code trotzdem für andere schwer 
verständlich schreibt, ohne dass diese deshalb zu doof sein müssen. Er 
merkt vielleicht nicht mal, dass der Code zu kompliziert ist.

Karl H. schrieb:
> Amateure glauben
> immer, man müsse in C möglichst kryptisch programmieren; möglichst viel
> in eine Zeile quetschen; möglichst undurchschaubare Sonderzeichenorgien
> kreieren um bei den Profis anerkannt zu werden.

Dafür ist aber Perl viel besser geeignet ;-)

Jay schrieb:
> Nein, das ist kein Modem-Rauschen.

Sieht aber so aus ;-)

Jay schrieb:
> Wer Seite 21 dieser Präsentation gesehen hat
> http://www.vaxman.de/publications/apl_slides.pdf findet plötzlich, dass
> C oder Perl extrem langweilige und lesbare Programmiersprachen sind.

Ja ja:
* Being able to write APL programs does not normally imply
  that you are able to read APL programs – not even your own!
* This has APL earned the notation of being a write only
  language

> Ich erinnere mich auch noch an REC. Ein Beispielprogramm aus
> http://delta.cs.cinvestav.mx/~mcintosh/cellularautomata/REC_files/rec25.pdf
> sieht so aus
>
>

1

> ([-2]J,([-2]K,

2

> (VV*UU*+PPPP****VV*UU*[-1]*+V*U*[8]*P*[-1]*+

3

> (N".W;" W;),V[.054]+K,!74!:;)

4

> "←-W"↓WU[.08]+J,!50!:;);)

5

>

>
> Nein, das ist kein Modem-Rauschen.

Mja, Brainfuck und Whitespace sind da auch nicht viel besser ;-)

Rolf M. schrieb:
> Auf der anderen Seite erwarte
> ich von einem professionellen Programmierer aber auch, dass er nicht
> gleich verzweifelt, nur weil ein Konstrukt mal eine Stufe komplizierter
> ist als der Trivialfall. Schließlich kriegt auch der Geld dafür.

Kein wirklicher Profi wird an einer solchen Zeile

1

if (x && (++x % 2))

verzweifeln oder gar dran scheitern ... aber darüber den Kopf schütteln 
- und gerade deshalb ist er sein Geld wert ;)

Jay schrieb:
> Ich erinnere mich auch noch an REC.

Ich höre heute zum erstan Mal davon.

Hast du dich tatsächlich einmal damit beschäftigt? Wenn ja, in welchem
Zusammenhang?

> Ein Beispielprogramm aus
> http://delta.cs.cinvestav.mx/~mcintosh/cellularautomata/REC_files/rec25.pdf
> sieht so aus
>
> ([-2]J,([-2]K,
> (VV*UU*+PPPP****VV*UU*[-1]*+V*U*[8]*P*[-1]*+
> (N".W;" W;),V[.054]+K,!74!:;)
> "←-W"↓WU[.08]+J,!50!:;);)
>
> Nein, das ist kein Modem-Rauschen.

Natürlich nicht. Das Programm ist absolut selbsterklärend, auch für
einen wie mich, der von der Sprache noch nie etwas gehört hat.

Naja, fast selbsterklärend ;-)

Ich habe es spaßeshalber mal in C umgeschrieben:

1

#include <stdio.h>

2

#include <math.h>

3

4

int main(void) {

5

  double v, u;

6

  int j, k;

7

8

  u = -2;

9

  for(j=0; j<50; j++) {

10

    v = -2;

11

    for(k=0; k<74; k++) {

12

      if(pow(v*v+u*u, 5) - pow((v*v-u*u)*v*u*8, 2) < 0)

13

        putchar('.');

14

      else

15

        putchar(' ');

16

      v += 0.054;

17

    }

18

    putchar('\n');

19

    u += 0.08;

20

  }

21

  return 0;

22

}

Lustig zu lesen ist auch dieser Artikel zu REC:

  http://arxiv.org/pdf/0905.0737

Auszüge daraus:

1

REC (Regular Expression Compiler) is a concise programming language

2

development in mayor Mexican Universities at end of 60's which allows

3

students to write programs without knowledge of the complicated syntax

4

of languages like FORTRAN and ALGOL.

1

... the interpreter REC Fortran was writing for Gerardo Cisneros at the

2

beginning of computing in Mexico, which marks a milestone in software

3

development in Mexico, ...

REC ist also sozusagen eine Programmiersprache für Dummies und stellt
einen Meilenstein der Softwareentwicklung in Mexiko dar. Das Zeug, das
die damals rauchten, muss schon heftig gewesen sein ;-)

Yalu X. schrieb:
> Ich habe es spaßeshalber mal in C umgeschrieben

Nice.

Eric B. schrieb:
> Jay schrieb:
>> Wer Seite 21 dieser Präsentation gesehen hat
>> http://www.vaxman.de/publications/apl_slides.pdf findet plötzlich, dass
>> C oder Perl extrem langweilige und lesbare Programmiersprachen sind.
>
> Ja ja:
> * Being able to write APL programs does not normally imply
>   that you are able to read APL programs – not even your own!
> * This has APL earned the notation of being a write only
>   language

Da kommen Erinnerungen hoch.
Mit APL bin ich nie warm geworden. Und ja, ich hatte 1 Semester lang 
APL. Aber ehrlich, es war eine Qual. Und das sag ich als einer, der auf 
der Uni keine einzige angebotene Programmiersprache ausgelassen hat.