Diskussion:C-Programmierung: Kontrollstrukturen

geschachtelte for schleife

Könnte man bitte die geschachtelte Schleife etwas genauer erklären? Wozu braucht man Zahl, bzw. wie funktioniert diese geschachtelte Schleife? --84.112.135.157 22:05, 4. Jan. 2010 (CET)

eine "geschachtelte Schleife" ist eigentlich nichts Erwähnenswertes. Ich empfinde es eher als verwirrend, weil man meinen könnte, das sei ein besonderes Konstrukt. Ist es natürlich nicht. Was in einem Schleifenrumpf steht, wird eben mehrmals ausgeführt (hier im Beispiel 11-mal). Punkt. Was das nun ist, weitere Schleifen, Funktionsaufrufe oder sonstige Anweisungen, ist völlig egal. Wozu Zahl? Berechtigte Frage, denn der aktuelle Zählerstand lässt sich auch aus den Zählern der einzelnen Schleifen berechnen, also statt "Zahl++" ginge auch "j + (i-1) * 10". Aber das dürfte dann bei einigen noch mehr Stirnrunzeln verursachen ;-) --84.131.153.113 22:37, 4. Jan. 2010 (CET)

Müsste die innere Schleife nicht 1 bis 10 ausgeben? Warum wird daraus 110, 110 ist doch größer als 10? Ich bin zu blöd dafür. --84.112.135.157 09:24, 5. Jan. 2010 (CET)

Der Startwert für Zahl wird nur einmal gesetzt: Zahl=1. Die innere Schleife hat 10 Durchläufe und die äußere hat 11 Durchläufe und ruft somit die innere Schleife 11-mal. Das heißt, die Anweisung Zahl++ wird 11x10mal, also 110-mal ausgeführt, Zahl nimmt also im Laufe des Programms die Werte 1 bis 110 an (bzw. bis 111, wird nur nicht mehr ausgegeben). --84.131.152.164 10:12, 5. Jan. 2010 (CET)

Danke, jetzt hab ichs verstanden. --84.112.135.157 19:24, 5. Jan. 2010 (CET)

Kleine Ungenauigkeit

In Java ist goto schon ein Schlüsselwort *g* --Bastie 07:55, 6. Okt 2005 (UTC)

if

Ich halte die Definition der if-Kontrollstruktur für falsch. IMHo ist if wie folgt zu definieren...

if <wahrheitswert> <ausdruck> [else <ausdruck>]

Die dargestellte Struktur ist lediglich eine Ineinanderschachtelung mehrerer if --Bastie 07:29, 6. Okt 2005 (UTC)

Verschiedene Änderung

Hab gerade gemerkt, dass nach der neuen Rechtschreibreform sowohl Spaghetti wie auch Spagetti richtig ist. Die Änderung von mir kann also wieder rückgängig gemacht werden, wenn’s jemand anders besser gefällt.

Das der Satz "Allerdings haben die letzen beiden Varianten den Nachteil, dass nicht so leicht ersichtlich ist, dass x um eins erhöht werden soll." wurde entfernt. Hab’s jetzt mal geändert eingefügt und heißt jetzt "die meisten Programmierer benutzen eine der ersten beiden Varianten, da sie der Meinung sind, dass schneller ersichtlicht wird, dass i um eins erhöht wird." Dürfe jetzt mehr NPOV sein. Wenn ich mich nicht stark täusche wird i = i + 1 und i += 1 sehr selten benutzt.

Auch wurde das Beispiel while((a | b) != 0) entfernt. IMHO kann man gar nicht genug Beispiele bringen und anhand eines Beispieles wird schneller klar was der Autor eigentlich sagen will.

"Dies ist aber hier wegen des ominösen EOF-Zeichens (EOF = end of file: markiert das Dateiende) nicht möglich. Denn EOF ist ein negativer Wert vom Typ int , so dass kein "Platz" mehr in einer Variable vom Typ char ist". Ich kann auch hier täuschen, aber meiner Ansicht nach hört sich das sehr langweilig an. Dies ist schließlich kein Wikipediaartikel und ich bin der Meinung, dass man sprachlich ruhig etwas lockerer formulieren kann. -- Daniel B 20:41, 5. Aug 2005 (UTC)

Nun, ich bin auch kein Deutschexperte und schreibe gewöhnlich nach den „alten“ Regeln, wobei die ja sowieso wieder schrittweise eingeführt werden. Außerdem ist die „Reform“, wenn man den Umfragen Glauben schenken kann, doch recht unbeliebt. Weiterhin führt sie zu Unsicherheiten und mehr Fehlern, verschlechtert die Lesbarkeit und verlangt grammatikalisch fragwürdige Schreibweisen. Aber verbindlich ist sie dafür nicht, ausgenommen für Schulen und Beamte.

„die meisten Programmierer benutzen eine der ersten beiden Varianten, da sie der Meinung sind, dass schneller ersichtlicht wird, dass i um eins erhöht wird.“ - Für einen C-Anfänger wird das nur schwer nachvollziehbar sein. Als ich angefangen habe C zu lernen, kamen mir Konstrukte wie i++ oder i+=j wie ein „Geheimcode“ vor. Dagegen war mir aus i=i+1 die Bedeutung sofort klar. Die Variante i++ bzw. ++i wird wohl eher aus Tradition und wegen der Einsparung an Tipparbeit gebraucht. Natürlich wird für einen erfahrenen C-Programmierer ein i++ sicher schneller ersichtlich sein.

Das Beispiel while ((a | b) != 0) schien mir ein wenig aus der Luft gegriffen, da hier nichts über die Intention dieser Zeile gesagt wird: Was ist a und b? Welche Anweisungen sollen im Schleifenkörper stehen? usw. Schließlich ist while (a | (b != 0)) bzw. while (a | b != 0) genauso legitimer C-Code und die Reihenfolge der Auswertung der Teilausdrücke, die man wünscht, wird in diesem Beispiel ja nicht genannt.

„IMHO kann man gar nicht genug Beispiele bringen und anhand eines Beispieles wird schneller klar was der Autor eigentlich sagen will.“ - Schon richtig, wenn sie gut erklärt sind. Zu viele Beispiele können aber auch unnötig den Text aufblähen.

„Ich kann auch hier täuschen, aber meiner Ansicht nach hört sich das sehr langweilig an.“ - Der Grund meiner Änderung war hauptsächlich der Stil:

• Deine Fassung: „Für die Speicherung eines Zeichenwertes genügt ... eine Variable vom Typ Character. Der Grund dafür, ... liegt im ... : ... Allerdings ist EOF ein negativer Wert vom Typ“
• Meine: „Dies ist aber ... nicht möglich: Denn EOF ist ein negativer Wert vom Typ ...“

Der Grund dafür ist, daß EOF ein ... Wert vom Typ int ...

Gruß

Thomas-Chris

--Thomas-Chris 23:26, 5. Aug 2005 (UTC)

Weiterhin führt sie zu Unsicherheiten und mehr Fehlern, verschlechtert die Lesbarkeit und verlangt grammatikalisch fragwürdige Schreibweisen. Aber verbindlich ist sie dafür nicht, ausgenommen für Schulen und Beamte. Mit der Schreibweise will ich mich jetzt eigentlich nicht weiter auseinandersetzen. Mach meine Änderung wieder rückgängig wenn dir eine andere Schreibweise besser gefällt.

Als ich angefangen habe C zu lernen, kamen mir Konstrukte wie i++ oder i+=j wie ein „Geheimcode“ vor. Dagegen war mir aus i=i+1 die Bedeutung sofort klar. Die Variante i++ bzw. ++i wird wohl eher aus Tradition und wegen der Einsparung an Tipparbeit gebraucht. Natürlich wird für einen erfahrenen C-Programmierer ein i++ sicher schneller ersichtlich sein. Da hast du natürlich recht, für einen Anfänger ist die Schreibweise i++ und ++i natürlich schwerer nachvollziehbarer. Das Beispiels sollte deshalb eigentlich nochmals verdeutlichen, dass dies eine andere Schreiweise für i = i + 1 ist. Ich wollte eigentlich nur eine Begründung liefern, warum in diesem Buch dennoch immer i++ bzw. ++i verwendet wird. Jemand der C lernt sollt sich IMHO möglichst bald an diese Schreiweise gewöhnen, weil sie nun mal sehr häufig verwendet wird. Das mit der Tipparbeit hab ich jetzt auch mal eingefügt. Ich zumindest würde aber auch über die Schreibweise i = i + 1 stolpern weil ich da lesen muss: "addiere 1 zu i und weise den Wert der Variale i zu" und bei i++ sofort lesen kann "erhöhe den Wert der Variable i um eins".

Das Beispiel while ((a | b) != 0) schien mir ein wenig aus der Luft gegriffen, da hier nichts über die Intention dieser Zeile gesagt wird. ACK. Das hatte ich nicht berücksichtigt. Ich habe das Beispiel wieder entfernt.

• Deine Fassung: „Für die Speicherung eines Zeichenwertes genügt ... eine Variable vom Typ Character. Der Grund dafür, ... liegt im ... :: ... Allerdings ist EOF ein negativer Wert vom Typ“
• Meine: „Dies ist aber ... nicht möglich: Denn EOF ist ein negativer Wert vom Typ ...“

Ich glaube ich stehe da gerade auf dem Schlauch.

Ich hoffe ich hab dich jetzt nicht irgendwie abgeschreckt, weil ich ein paar Änderungen wieder rückgängig gemacht habe. Wahr in einigen Punkte wohl auch etwas zu voreilig. Grüße -- Daniel B 07:00, 6. Aug 2005 (UTC)

Fehler

1. While-Schleife Code Beispiel 1 fehlt das "return 0;"

2. Ich muss dor 2x hintereinander STRG+Z verwenden (Win XP SP2 in der CMD)

3. 05 int i, j, Zahl=1;//<<<<<<------ Ich dachte im Buch werden Variablen immer klein geschrieben?

So das war erstmal alles, ansonsten ist das bis jetzt ein super Buch!

--85.127.135.249 19:24, 12. Aug. 2007 (CEST)

Ist etwas weniger nicht etwas mehr?

1. include <stdio.h>

int main(void) {

 double i;
 for(i = -10; i <=10; i++)
 {
   if(i == 0)
    continue;
   printf("%lf \n", 1/i);
 }
 return 0;

}

Mir kommt das "1/i" in Zeile 10, des Beispiels von "continue in Schleifen", doch etwas zu dick aufgetragen vor, das mehr Verwirrung stiftet als zu erklären. Wenn man es so Compiliert und ausführt kommt diese Ausgabe: -0.100000 -0.111111 -0.125000 -0.142857 -0.166667 -0.200000 -0.250000 -0.333333 -0.500000 -1.000000 1.000000 0.500000 0.333333 0.250000 0.200000 0.166667 0.142857 0.125000 0.111111 0.100000 Wo so gut wie jeder Anfänger erst mal in einem schockmoment verdutzt einher schaut. Da nicht das erwartete zählen von -10 bis +10 auftaucht, sonder das.

Wäre es nicht besser die "1/" aus "1/i" in Zeile 10 zu entfernen, damit die Ausgabe, wie man sie eigentlich erwartet, aussieht?: -10.000000 -9.000000 -8.000000 -7.000000 -6.000000 -5.000000 -4.000000 -3.000000 -2.000000 -1.000000 1.000000 2.000000 3.000000 4.000000 5.000000 6.000000 7.000000 8.000000 9.000000 10.000000

Außerdem würde ein "float" als Daten-typ für das "i" in Zeile 5 doch voll und ganz ausreichen, oder soll der Daten-typ "double" dort eine bestimmte Bedeutung besitzen? Auch ein "int" Daten-typ würde reichen, dann müsste man aber noch in Zeile 10 das "%lf" durch "%i" abändern/austauschen.

//edit by: Linux-Distri.-user.

Das 1/i ist doch gerade der Witz. Das continue verhindert, dass durch 0 geteilt wird. --84.131.154.12 19:20, 22. Mai 2009 (CEST)

Dann verstehe ich den clou nicht. Das Beispiel sollte einem doch das "continue" näher bringen, nicht? Deshalb auch das Beispiel mit dem der Abzählung von -10 bis +10. Da hier nichts geteilt wird, bräuchte man das "1/i" doch nicht oder stehe ich noch irgendwo auf dem Schlauch? Wieso also, um Himmels willen, sollte man das Ergebnis von "i" durch "1" Teilen?

Ganz ruhig. Es wird durch i, nicht durch 1, geteilt.

Beide Varianten funktionieren, nur gibt die Variante ohne "1/i" mir ein besseres Verständnis von "continue" und gibt auch den erwarteten (klaren) Text aus und nicht irgend welche Zahlen die für mich keinen Sinn ergeben.

Wieso gibt dir das Programm ohne "1/i" ein besseres Verständnis? Ohne die drohende Division durch 0 (wenn da also z.B. nur "i" statt "1/i" stände), gäbe es doch gar keinen Grund, mittels if(i == 0) continue; die 0 zu überspringen. Grrr, was schreib ich mir eigentlich die Finger wund; das steht ja bereits unter dem Quellcode. --84.131.154.12 21:04, 22. Mai 2009 (CEST)

Ganz genau! Da es sonst keinen Sinn machen würde, wenn man das 1/i weglassen würde, sollte man lieber ein neues Beispiel für continue schreiben. Hier soll ja nicht die Teilung von Bedeutung sein sonder das continue, mit dem man den weiteren Code überspringen und noch mal vorn anfang anfangen kann. Klar scheint es sinvoll zu sein, das continue in einem Beipiel zu nutzen/aufzuzeigen in dem es auch gebraucht wird, doch leider sorgt das hier ja für mehr Unverständnis als für Verständnis. Bitte berücksichtigt auch die noobys, die sich zum ersten mal mit so einer Proger-sprache beschäftigen. Da kann das wirklich zu einem "überraschungs.effect" führen.

p.s.: Was ist mit meiner Anfrage bezüglich dem "double"? Würde da ein float oder int nicht voll und ganz ausreichen? Beide Varianten lassen sich problemlos compilieren und ausführen.

Etwas beim Beispiel der verschachtelten For-Schleife stimmt nicht

1. #include <stdio.h>
2.  
3. int main()
4. {
5.   int i, j, Zahl=1;
6.   for (i = 1; i <= 11; i++)
7.   {
8.      for (j = 1; j <= 10; j++)
9.         printf ("%4i", Zahl++);
10.      printf ("\n");
11.   }
12.   return 0;
13. }

Es scheint als ob die Zeile 9 falsch sei. Sie verursacht beim Compilieren eine Fehler Meldung bezüglich einer "unverträglichen impliziten Deklaration der eingebauten Funktion »printf«. Liegt wahrscheinlich an der >>%4i<<. Kann sich das mal jemand genauer ansehen?

//edit: Ob diese Fehlermeldung auch unter eine Windows Plattform auftritt, weiss ich nicht. Doch unter meiner Linux Distri. funktioniert es leider nicht. Selbst wenn ich die debuger weg lasse.

Bei mir funktioniert es (unter Mac OS X). Für mich klingt der Fehler nach fehlendem Header. Hast du die stdio.h bei dir lokal auch wirklich mit eingebunden? --Borstel 08:17, 19. Mai 2009 (CEST)

//edit: Sorry, falscher Alarm. -Hat sich geklärt.- War gestern wohl etwas zu lange am Arbeiten und konnte wohl i von I, im header, nicht mehr unterscheiden. ^^; Borstel: Kaum deine Nachricht heute früh gelesen und in den Quellcode geschaut, schon etwas geschämt. -Kommt nicht mehr vor, werde ab jetzt etwas besser aufpassen und mehr als 1-Tag nach dem/einem Bug suchen.

Wünche dir noch einen angenehmen restlichen Tag, bye.  :)

Beispiel zu break

Frage von IP-Seite Benutzer_Diskussion:84.131.130.146 hierher kopiert:

Leider kann man die Schleife, aufgrund der fehlenden beenden-anweisung, nicht mehr verlassen. Da die do-while-schleife den Code-Block sowieso wiederholt ist das "j" überflüssig/unpassend/nutzlos. Deshalb sollte es lieber auf "N" prüfen. Leider scheint es noch ein paar probleme mit der "(uswahl != 'n' || auswahl != 'N')" zu haben. Wenn dir eine Lösung dazu einfällt kannst ja gerne posten. //edit: Mit nur einem n oder N funktioniert es (fast) einwandfrei.

Warum n/N besser ist als j/J, verstehe ich nicht. Wenn ich gefragt werde "Nochmal?", dann möchte ich wissen, was ich machen muss, um die Frage bejahen zu können. Ansichtssache, denke ich.

Warum funktioniert "(auswahl != 'n' || auswahl != 'N')" nicht? Genau hingucken! Die Bedingung ist immer wahr, egal für welches Zeichen.

Aber: Das Programm ist trotzdem Murks. Geb ich was anderes als j/J ein, beende also die do-while-Schleife und somit das Programm, gibt es ein "Segmentation fault" (oder andere Unliebsamkeiten). Klar, scanf() will nämlich noch ein '\0' anhängen, aber auswahl hat nur Platz für ein Zeichen. Da sollte man vielleicht mit getchar() arbeiten. --84.131.130.146 22:30, 24. Mai 2009 (CEST)

So, korrigiert. Leider ist dieses Tastaturpuffer löschen müssen unschön für Anfänger. Falls jemand eine bessere Lösung weiß ... --84.131.130.146 23:22, 24. Mai 2009 (CEST)

Sorry, habe mich wohl falsch ausgedrückt. Es geht mir ja nicht um's be'ja'n sonder um das beenden der endlos-schleife. (beenden mit nein >>n<<) mann könnte ja auch b für beenden nehmen. :)

Das mit "while( auswahl != 'n' || auswahl != 'N' );" funkst leider nicht. Weiss auch nicht woran das bei mir liegen mag. Normal müsste es die Schleife beenden, doch das geschieht leider nicht, wenn beide da stehen. -Ist ja egal, könnte bei mir eine ausnahme sein-

Nein ist es nicht. Geh doch logisch ran. Da steht (auswahl ungleich n oder auswahl ungleich N). Wenn Auswahl gleich n ist, ist automatisch auswahl ungleich N. Und da Beides mit oder verknüpft ist, reicht es ja, wenn eins von beiden wahr ist. D.h. statt while( auswahl != 'n' || auswahl != 'N' ); hättest du auch while(1); schreiben können ;-)

Jedenfalls zu dem scanf() habe ich auch eine Verbesserung gepostet, die du leider mit dem Rest verwrofen hast. Man kann da: >>scanf( "%1s", &auswahl );<< oder >>scanf( "%c", &auswahl );<< verwenden. Beide methoden würden nur ein Zeichen entgegen nehmen.

Nein, bei %1s wird auch '\0' angehängt und es gibt einen "Segmentation fault". Das mit %c geht tatsächlich, aber auch da muss der Tastaturpuffer gelöscht werden. --84.131.130.146 23:49, 24. Mai 2009 (CEST)

Habe ein neues Beipiel für die break-Anweisung rein genommen. Leider ist sie noch etwas "Aufarbeitungs.bedürftig", dashalb schau sie dir doch bitte mal an. Das vorherige Beispiel habe ich weiter unten gelassen(da ich nicht wusste wie man ein einzelnes Abschnitt anfertigt/anlegt) mit neuer Überschrift. Wenn du da noch etwas dazu schreiben würdest, wäre der Artikel viel Anfäger freundlicher und verständlicher. //edit: Auch wenn mein Beispiel funktioniert, gibt es doch noch ein "Segmentation fault" meldung unter den anderen Ausgaben aus.

"Aufarbeitungsbedürftig" ist nett gesagt. Da funktioniert und stimmt rein gar nichts. Wieso ist z.B. "eva" auch ein gültiges Passwort?

..... Scheint als ob er nur das "e" einliest und den Rest ignoriert. Das heißt das man alles was mit "e" oder "only e" als Passwort benutzen könnte. Was aber den Sinn verfehlen würde. Habe es jetzt auf "only Zahlen" umgestellt, damit wäre das Problem behoben. Keine Fehlermeldungen wärend dem Compilieren oder ausführen sollten mehr auftreten. .....

Sorry, das kann man nur wieder komplett löschen. Wer Daten in den Speicher lädt, ohne vorher dafür Speicher reserviert zu haben (aufm Stack oder Heap), kann nicht C gelernt haben.

..... Das mit dem Speicher reservieren wurde bis jetzt noch nicht in dem ausmaße durchgenommen, den man hier bräuchte. Daher kann's bis hier Irrelevant sein, es zu wissen oder nicht. Aber $ich hoffe $ich werde es noch lernen, in den nachfolgenden Kapitlen. :) .....

Dann: Wo hast du her, dass man Zeichenarrays mit == auf Gleichheit prüft? Kann nur frei erfunden sein. Dann: Beim Kompilieren müsste es eine Warnmeldung für eine der ersten Zeilen geben. Die Nichtbeachtung ist grob fahrlässig.

..... Kamm ja bis jetzt, hier, noch nicht vor. Deshalb habe ich es auch leider so gemacht wie bisher beschreiben stand: Vergleichen mit "==". Wird sich aber hoffentlich auch noch ändern, wenn ich weiter mit diesem Buch bin. :) .....

Dann: Wenn da ein break ist, wozu dann noch der else-Zweig? Zumal die eine printf-Anweisung im Zweig steht, die zugehörige 2. aber dahinter.

..... Der else Zweig ist dafür da, wenn man ein falsche Passwort eingibt. Man würde sich doch sicher wunder, wenn man immer und immer wieder nur das "Bitte geben sie ein Passwort ein" sieht und nicht versteht das man etwas falsch eingegeben hat. So sieht man: "Oh, habe mich vertippt, dann noch mal richtig eingeben". Das zweite "printf" das hinter der else-Anweisung (aber nicht in ihr) steht, habe ich absichtlich da plaziert, damit man den Sinn von break richtig und in vollem Umfang versteht. So kann man verstehen/erkennen, dass durch eine break-Anweisung die schleife direkt beendet wird und dann der code der nächsten Anweisungen ausgeführt wird. Doch ohne break-Anweisung wird er den else-Block und die danach folgenden code-Zeilen(zweite printf Anweisung) ausführen, befor er die Schleife widerholt. Hat also alles seinen Sinn und Richtigkeit. :) .....

Ich hab leider absolut nichts verstanden. Zwischen ...

       if( passwd == eingabe)
       {
           printf( "Passwort korrekt\nEnde" );
           break;
       }
       else
       {
           printf( "Das Passwort ist nicht korrekt\n" );
       }
       printf( "Bitte versuchen sie es nochmal\n" );

... und ...

       if( passwd == eingabe)
       {
           printf( "Passwort korrekt\nEnde" );
           break;
       }
       printf( "Das Passwort ist nicht korrekt\n" );
       printf( "Bitte versuchen sie es nochmal\n" );

gibt es logischerweise keinerlei funktionalen Unterschied. Das else ist völlig überflüssig.

/*Ja, war mir auch von Anfang an klar. Es geht mir ja nur um das Prinzip, dass es auch möglich wäre weiteren Code auszufüren, wenn die Eingabe nicht mit dem Passwort übereinstimmt und auch Code der danach Folgen könnte.*/

Wenn in einem if-Block ein break steht, ist ein else-Block einfach nur schwachsinnig (sorry) und untauglich, ein Prinzip zu verdeutlichen. Dass der Code hinter dem if-Block ausgeführt wird, wenn die Bedingung nicht erfüllt ist, ist doch auch so klar.

..... Bin dir nicht böse. Bin ja noch kein "Fachmann" in/für C, kann daran auch im Moment nichts ändern ausser weiter fleißig zu lernen. ..... Lerne also erstmal C möglichst komplett (und möglichst mit einem guten Buch). Vorher ist eine konstruktive Mitarbeit schwierig. -- 84.131.156.3 18:35, 25. Mai 2009 (CEST)

..... Bin ja gerade dabei, mit diesem Buch, C möglichst komplett zu lernen. Deshalb sehe ich ja auch alles noch aus der nooby-Sicht und kann deshalb ja auch behilflich sein es bewerten zu können um es weiter zu verbessern. Meinst du nicht auch das man solche Leutchen bräuchte? :)

Ganz ehrlich, nein. Ein Newbie kann Stellen aufzeigen, wo es Verständnisprobleme gibt. Umsetzen auf vernünfigem Niveau können das nur die Fachleute.

/*Genau darauf bin ich ja aus! Ich möchte ja aufzeigen und hoffen das jemand mit Fachwissen sich darum kümmer. Du scheinst es die ganze Zeit überlesen zu haben oder ich habe mich nicht deutlich genug ausgedrückt.*/

Wenn dir was nicht passt, schreib es auf die Diskussionsseite und warte, bis sich ein Fachmann des Problems annimmt. Da ist Usus, wenn man selbst kein Fachwissen hat.

Bei meinen Veränderungen hier, bringe ich also nur das ein was mich gestört/behindert hat oder unnötig verkompliziert wurde.</(nooby-Sicht)>

Ja, was dich aus deiner sehr individuellen und erstaunlichen Sicht stört. Dabei kommt dann sowas raus, wie diese komische else-Geschichte, die sicherlich nur du logisch findest.

/*Nur ein Verstädnigungs Problem zwischen uns. Alles hat schon seinen Sinn. :)

Nein. Absolut nicht. Überflüssiger Quellcode hat nie Sinn, schon gar nicht in einem Lehrbuch.

Freut mich das du "Vorher ist eine konstruktive Mitarbeit schwierig" geschrieben hast und nicht "Vorher ist eine konstruktive Mitarbeit unmöglich".

Tja, da war ich dann doch zu diplomatisch.

Deshalb werde ich weiterhin versuchen mein bestes zu geben um hier weiter zu helfen, um mir und anderen das lernen (hier) zu vereinfachen. Ich hoffe du hast nichts dagegen.

Ist nicht 'mein' Buch. Da es schon so nicht besonders toll ist, liegt mir auch nichts dran. Deswegen werde ich da auch nicht weiter versuchen, gegenzusteuern. Wenn du dich partout berufen fühlst, ohne jegliches Fachwissen, Fachbücher "verbessern" zu müssen, dann sei es so.

/*Was findest du den nicht besonder toll daran? Bis jetzt war es doch recht normal/lehrreich. Wenn dir etwas besseres einfällt kannst ja gerne rein posten/verändern/abändern/erweitern, damit es ein "tolles/tolleres" Buch wird. Darauf baut ja Wikipedia/books auf. ;) */

Deine Bearbeitungen einfach nur schlecht, schlechter als das Buch selbst (allein schon wegen der gut 2 Dutzend Rechtschreib- und Zeichensatzfehler, eine Frechheit). Jetzt haben wir zwei krude Beispiele zu break, wo es ein ganz simples auch täte. Nächsten Monat kommt der nächste Ahnungslose mit so einem Monster-Ego (ist das eigentlich ein Hauptstädterproblem? [Rhetorische Frage]) und meint, seinen Mist abladen zu können. Da es keinen Verantwortlichen/Maintainer für das Buch gibt, bleibt natürlich alles so stehen. So schreibt man keine Bücher, auch hier nicht. Fachbücher werden ausschließlich von Fachleuten geschrieben, jeder andere mache bitte seine Einwendungen auf der Diskussionsseite.

//*Sorry, ist aber besser das du nicht dafür verantwortlich bist. Ich kann doch nicht's dafür das du einen schlechten Tag/Leben hattest/hast. Da brauchst du nicht gleich Persönlich zu werden. Da behauptest DU auch noch das ICH ein Monster-Ego hätte? Schon alleine die Tatsache das du den Begriff "Fachleute" in fast jede zweite Zeile gestopft hast, sagt auch schon alles... Meine Rechtschreib- und Zeichensatzfehler gehen dich nichts an. Das sind meine und mir passte es. Ich werde mich weder (noch) mehr bemühen, noch etwas daran ändern. Wenn sie dich stören koriegiere sie einfach selbst und hör auf herum zu jammern! Reden aber nichts machen, solche Leutchen habe ich gerne... -_- Gerade die Art wie man hier bei wikibook Bücher schreiben kann, finde ich besonders Sinnvoll und effectiv um eins anfertigen zu können.(meine Meinung muss ja nicht mit der von anderen Meinungen übereinstimmen). Wenn du irgendwann einmal einen besseren Tag hast, von deinem hohen Ross herunter steigst und lust verspürst, deine Ideen in einem Buch, mit anderen fleißigen Bienchen, einzubringen, um es für alle so gut und verständlich wie möglich darzubieten, dann freue ich mich jetzt schon auf deine Veröffentlichungen. //edit: Da diese Diskussion langsam ausufert bitte ich dich nicht auf diese post zu antworten.

Auf gute Zusammenarbeit. :)

Nein, leider nicht. EOD. --84.131.156.3 21:13, 25. Mai 2009 (CEST)

Es aber wirklich EOD für mich. --84.131.156.3 22:23, 25. Mai 2009 (CEST)

Programmierstil

Hallo, Sollte man nicht eher von Anfang an mit Geschweiften Klammern arbeiten, und dann die Ausnahme erklären dass man diese bei einer einzelnen Anweisung weglassen kann? Dies würde ich dann für alle Abschnitte gemeinsam erwähnen, und auch ein Beispiel zur verschachtelten Anweisungen dran bringen (zwei for ineinander), und dort dann die wirkliche Bedeutung von else if erklären. Den Rest der Seite sollte man dann in gutem Programmierstil schreiben. Es bringt nichts wenn man Leuten sagt das etwas kein guter Programmierstil ist und dann trotzdem Beipsiele in schlechtem Programmierstil bringt.

PS. Sollte man eine Warn-Vorlage (Achtung: schlechter Programmierstil. Vermeiden da er zu Unleserlichkeit und Fehleranfälligkeit neigt ...) erstellen?

Gruß, Michael --Michael2402 20:48, 15. Dez. 2009 (CET)

Falche Erklärung des Beispiels "i++ == 5"

  i = 7;

  if(i++ == 5 || (i += 3) == 4)

Im Text wird beschrieben, dass zunächst i um eins erhöht und dann mit dem Wert 5 verglichen wird. Da der Operator allerdings Postfix ist, wird i erst nach dem Vergleich erhöht. So liefert das folgenden Codebeispiel "true":

  int i = 7;
  if (i++ == 7 || (i += 3) == 4) {
    printf("true\n");
  } else {
    printf("false\n");
  }

-- 85.212.8.143 09:06, 11. Sep. 2016 (Signatur nachgetragen von: Jürgen 12:20, 11. Sep. 2016 (CEST)-- bitte signiere deine künftigen Beiträge selbst mit 4 Tilden ~~~~)

Du hast recht. Ich wage trotzdem keine Korrektur des Beispiels: Es soll das Zusammenspiel und die Reihenfolge von Operatoren erläutern, und das unter der Überschrift "Tastaturpuffer leeren". Ich möchte noch nicht einmal vorschlagen, ob dieser Abschnitt besser im vorigen Kapitel "Operatoren" aufgehoben wäre. Vielleicht hast du eine Empfehlung. -- Jürgen 12:20, 11. Sep. 2016 (CEST)