Diskussion:C-Tutorial: Unterschied zwischen den Versionen

Aktuelle Version vom 22. Mai 2007, 20:21 Uhr

Habt ihr ihr auch texte aus Buchern oder Tutorials hier reingesetzt?

Ich würde die Kapitelnummern weglassen. Wenn Du es mit den Gleichheitszeichen strukturierst reicht das völlig und ist übersichtlicher!

--Frank 22:49, 16. Dez 2005 (CET)

einige Anmerkungen

• main ist nicht vom Typ void, sondern liefert int. Einige Compiler unterstützen main auch als void, dazu müssen aber spezielle Schalter angegeben werden.
• C unterscheidet zwischen Groß- und Kleinschreibung bei allen Bezeichnern.
• Quellen werden besser lesbar, wenn man Leerzeichen benutzt, z.b. nach ',' in Argumentlisten oder Deklarationen
• Quellen werden besser lesbar, wenn man Code-Konventionen verwendet, z.b. Makro-Namen groß zu schreiben: DAS_IST_EIN_MAKRO, Funktionsnamen klein: eine_funktion() oder eineFunktion() und selber definierte Typen klein mit nachgestelltem _t: mytype_t
• an vielen Stellen ist falscher Code, der kein C ist! Bevor man so was in ein Tutorial stellt, sollte man sich im klaren sein, was C ist und was nicht. Etwa das Beispiel zu PERSON ist komplett inkorrekt und verwirrt mehr als er erhellt!
• An vielen Stellen werden Begriffe nicht korrekt benutzt, etwa "Deklaration" anstatt "Definition" oder umgekehrt. Dudem sollte geklärt sein, was der Unterschied überhaup ist.
• In C gibt es kein Typ boolean, bool o.ä. C ist kein Pascal. Ebenfalls nicht definiert sind TRUE und FALSE. Boolsche Variablen in C werden durch int abgebildet -- zumindest in Standard C.

Das Tutorial ist noch nicht perfekt. Jeder kann natürlich Korrekturen und Verbesserungen einbringen, einfach ändern. --Bernd 12:02, 20. Dez 2005 (CET)

Jeder hat meinen ganzen Respekt, wenn er sich die Arbeit macht und solche ausführlichen Artikel schreibt. Bitte das also als positive Kritik zu sehen. Aaaaaber: Grad bei einem Tutorial MÜSSEN auch die Details stimmen !! Und jeder Autor trägt da auch Verantwortung ! Bitte, die Autoren mögen den Artikel nochmal gaaaanz genau durcharbeiten. Es sind sehr viele Einzelheiten, die den Laien auf's Glatteis führen und den Wissenden die Nase rümpfen lassen.

• eine variable ist eine variable, das hat mit RAM prinzipiell nix zu tun
• Wieviele Daten passen in eine Variable ? (immer genau ein Datum)
• die Bitanzahl von int ist etwas differenzierter als dargestellt, ganz zu schweigen von "unsigned" Varianten
• In der Mitte von "for" steht keine Abbruchbedingung, sondern eine Laufbedingung
• "case sensitiv" heißt nicht, man muß kleinschreiben, sondern man muß drauf aufpassen

Bitte keine Codebeispiele, wo der Compiler sofort auszuckt. Das muß man ausprobieren oder nochmal lesen, bevor man einen Einsteiger frustrierten in die Wüste schickt. --PicNick 12:57, 20. Dez 2005 (CET)

Ihr könnt gerne alles verbessern, aber bitte keine Fehler einbauen. Ihr habt das Beispiel

intVariable = 123;  //entspricht in Pascal:  boolVariable:=true;
intVariable = 1;    //entspricht in Pascal:  boolVariable:=true;
intVariable = 0;    //entspricht in Pascal:  boolVariable:=false;

vermutlich falsch verstanden. intVariable ist ein Variablenname, daher darf es nicht int Variable lauten.

"aber bitte keine Fehler einbauen." Was ist mit "const" ? bleibt das so ? Es ist blöd, wenn da dutzende Leute immer gleichzeitig den selben Artikel beflastern müssen. --PicNick 12:24, 21. Dez 2005 (CET)

Ich bin erst mal fertig. Ihr könnt den Text also ergänzen / ändern wenn ihr wollt. Allerdings folgende Ergänzung von euch, "long long" bei den Typen, ist verwirrend. Man spricht von Double, "long long" ist kein echter Begriff aus der C Fachliteratur.

double ist eine Gleitpunktvariable während long long eine 8byte Ganzzahl ist. long long ist C99-Standard. veraltete Fachliteratur? :-) --Fluchtpunkt 03:08, 25. Dez 2005 (CET)

evtl sollte man sämtliche Compiler-, Betriebssystem- bzw. Programmspezifischen Sachen entfernen bzw umschreiben; zB gibt es unter linux (mit gcc als Standardcompiler) keine conio.h; Und Erklärungen wie "Drücken Sie [ALT] + [F5], um zum Ausgabebildschirm zu kommen!" sind für Menschen die nicht die selbe IDE wie der Schreiber nutzen eher verwirrend als nützlich. Allerdings müsste man sich darüber klar werden wie das ganze aussehen soll, ich würde nämlich einfach alles, was nicht überall funktioniert, ganz einfach rauskicken; vielleicht tuts aber auch ein Hinweis das dies und jenes nur da und dort funktioniert.

IDE-Optionen würde ich allerdings durch allgemeinere Anweisungen ersetzen, da bringt es relativ wenig einen Weg für alle 1000 Programme zu beschreiben. Bevor ich da aber irgendwas rumpfusche würde ich dazu lieber erstmal andere Meinungen hören.

man sollte sich imho auch auf reines ANSI-C (99?) beschränken um Neulinge nicht schon bei ihren ersten Gehversuchen mit pfuschigem Code zu "versauen". void main(void) ist da ein gutes Beispiel. Das erspart später auch Fragen wenn User mal an einen Compiler geraten der 100% korrektes ANSI-C will.

War oder ist eigentlich geplant das aus diesem Tutorial mal eins wird das mehr auf Mikrocontrolleranwendungen konzentriert ist? --Fluchtpunkt 03:08, 25. Dez 2005 (CET)

Es ist sicher nicht so einfach, ein C-Tutorial zu schreiben, ohne seine Zeilgruppe zu kennen. Kommt der Leser vom Nirwana oder ist er ein ausgepuffter XXX-Programmierer, der jetzt auch C schreiben will ? Sicher ist irgendeine PC-Workbench als Demonstrationsobjekt für so eine Einschulung weniger geeignet, und eine Spezialisierung auf Controller täte, glaub ich, allen dahingehenden Artikeln gut.

btw: Die Entfernung von "then" ist einserseit ok, gibt's in C ja nicht. Aber die offizielle Bezeichnung der Bedingung ist eben "if-then-else". Geht man eben auf Theorie oder Praxis ? Nächstes Problem wäre dann "select case", der beim C ja mit "switch" beginnt.

--PicNick 10:49, 25. Dez 2005 (CET)

zumindest hat dieses Textfeld mit dem if then else den Anschein das es sich um C-Code handelt. Und das produziert einen Compilerfehler. Pseudocode oder Vergleiche mit anderen Sprachen sollten zumindest so gekennzeichnet sein; zB als C-Kommentar. Denn idR tippt der blutige Anfänger einfach alles ab und drückt auf kompilieren. Und postet dann im Forum und beschwert sich das hier falsches Zeug steht. --Fluchtpunkt 03:57, 26. Dez 2005 (CET)

Es wäre vielleicht sinnvoll dieses Tutorial als grundlegendes nicht compilerspezifisches Tutorial in C zu verstehen. Damit man sich so ein kleinen Einblick vom Standard C machen kann. Eine praktische Einführung könnte man als Ergänzung zu dem GCC-Artikel vielleicht unter WinAVR ausbauen.

--Frank 14:03, 25. Dez 2005 (CET)

habe gerade mal ein paar Flussdiagramme erstellt und versuche die nach und nach in das Tutorial einzuarbeiten.

und mal noch ein paar Punkte zur Diskussion

• im Allgemeinen würde ich im Tutorial auf Konstrukte wie "if (foo) bar;" verzichten; sondern alles schön lehrbuchmässig mit { } machen. Das erspart imho einige Verwirrungen. Das es auch anders geht kann man am Ende in einer Art "Tipps und Tricks"-Sektion erklären.
• die Flussdiagramme und der Pseudo-C-Code ala Anweisung1; reichen imho aus. reale Beispiele wie i=2; statt Anweisung1 sollte sich der Leser selbst denken können. Soll heissen 3 mal dasselbe sagen erscheint mir unsinnig. Ich ändere das jetzt erstmal in der If-Anweisung so wie ich mir das vorstelle und hoffe auf Kritik.
• "Vergleiche von Variablen" sollte man imho mit zur If-Bedingung packen. Da passt es thematisch besser. Konstrukte wie i = a > 2; sind ja eher selten. so grundlegende Änderungen in der Struktur mach ich allerdings nicht einfach so. => Diskussion willkommen
• Vergleiche mit anderen Programmiersprachen, wie zB das fehlende then in C, braucht man imho zumindest im Tutorial nicht. Es würde den Rahmen sprengen alle Unterschiede zu gängigen Sprachen herauszustellen. Natürlich wären Tutorials der Art Pascal=>C toll, das hätte mir auch erspart das ich bei jeder neuen Sprache über die Grundsätze der Variablenzuweisung lesen musste; Aber für alle die nicht mit der je nach Autor erwähnten Sprache aufgewachsen sind wäre das Wissen wie etwas in einer anderen Sprache gelöst wird nutzloses Zusatzwissen; und das stiftet imho sehr viel Verwirrung "es gibt also ein then. Aber das wird in C nicht benutzt...". Ich denke ihr versteht worauf ich hinauswill.. würde das also lieber weglassen. Und lieber einen Artikel, ähnlich dem Quellcodevergleich, schreiben in dem man sieht wie man bestimmte Sachen unter der und der Sprache löst; allerdings passt das eher in ein Programmierwiki :) --Fluchtpunkt 03:57, 26. Dez 2005 (CET)

Wenn irgendwer mal auf die Idee kommt, ein Tutorial eine anderen Sprache zu schreiben (meinethalben Bascom) wird er bei den Schleifen- und Verzweigungskonstrukten wieder von vorn beginnen. Früher war's mal so, da hat man "Programmieren" erst grundsätzlich gelernt, und das Wissen dann mal in dieser, mal in jener Sprache angewandt. --PicNick 11:48, 26. Dez 2005 (CET)

Ich wäre in einem Tutorial auch mehr für die Standard Schreibweise in C. Du musst davon ausgehen das ein C Artikel sowieso selten von jemanden gelesen wird der sich für Bascom entschieden hat. Der Versuch mehrere ganz verschiedene Dinge in einem Artikel zusammenzufassen führt immer zu kommplizierten schwerer verständlich Artikeln. Warum sollte man in bascom die Schleifen etc. nicht wiederholen, Platz haben wir doch, Priorität können wir da auf Verständlichkeit legen. --Frank 12:37, 26. Dez 2005 (CET)

volatile

volatile ist keine Speicherklasse, es ist ein Qualifier (ebenso wie z.B. signed, unsigned oder const.

Was die Verwendung von volatile angeht wären noch die SFRs hinzuzufügen, und nicht jede Variable die in einer ISR verwendet wird muss volatile sein. Wenn z.B eine Variable nur in einer ISR verwendet wird (z.B um Ereignisse zu zählen), dann braucht sie nicht volatile sein. Trotzdem ist der Code ok. --SprinterSB 18:24, 24. Apr 2006 (CEST)

SFR? Jetzt stehe ich grade auf dem Schlauch... Das mit nur in der ISR glaubte ich mit dem Zusatz global erschlagen zu haben.

Gerade für Anfänger sehe ich in einer globalen nicht-volatile Variablen, die nur in einer ISR verwendet wird, die Gefahr, dass man dann später doch "mal eben so" von anderen Codeteilen darauf zugreift.

--Johannuhrmann 21:33, 25. Apr 2006 (CEST)

Die unkorrekte/fehlende Verwendung von volatile oder nicht atomarem Code ist einer der häufigsten Anfängerfehler, das stimmt. Andererseit ist es ein C-Tutorial (oder soll es mal werden), und da sollte man schon drauf achten, daß man die Dinge korrekt beschreibt. Und mach mal einem Anfänger klar, was der Unterschied ist zwischen

int volatile * ptr;

und

int * volatile ptr;

Zugegeben, das fordert an vielen Stellen einen Spagat zwischen Korrektkeit, Verständlichkeit und Pragmatismus. Anhand der Ausnahme könnte man auch erklären, warum es an der Stelle ok ist, volatile nicht zu nehemen. IMHO bringt das für das Verständnis mehr, als eine "muss immer sein" Klausel.

Weiterer Übelstand an der Stelle ist, daß C keine Vorstellung von ISRs hat (zumindest nicht im Standard, da muss jeder Compilerbauer sein eigenes Süppchen machen und ne API stricken). In einem Abschnitts "Interrupts", wo solche Hinweise vielleicht besser gefunden werden als unter "Speicherklasse" oder "Qualifier" (wer wird so spannende Abschnitte überhaupt anclicken?), hätte man zu Interrupts nicht viel zu sagen.

volatile ist übrigens nur die Hälfte der Miete. Wenn die betroffene Variable ein int ist, recht volatile nicht aus... In Fallstricke bei der C-Programmierung steht ein bisschen was dazu.

Bei dem Beispiel, wo eine globale Variable nur in einer ISR verwendet wird, könnte man auch eine lokale statische Variable nehmen, stimmt. Jedoch könnte es auch eine globale Variable sein, die nur in ISRs (die sich nicht gegenseitig unterbrechen können) verwendet wird. Einfach zu verstehen (oder zu erklären) sind die Feinheiten freilich nicht gerade. Hier ist dein Ansatz bestimmt besser und einfacher zu verstehen für den Neuling.

--SprinterSB 23:35, 25. Apr 2006 (CEST)

goto

Man sollte schon festhalten, dass "goto" ein absolut grauslicher Befehl ist, dessen Verwendung ein Ausdruck der Hilflosigkeit ist.

--PicNick 19:22, 17. Jul 2006 (CEST)

• Find ich nicht. Wenn man weiß, was man tut, ist goto sogar sehr nützlich. Beispielsweise um aus einem Tastatur-Abfrage-Switch in einer while(1) Schleife direkt an den "Endblock" eines Programmes zu springen, wenn der User ESC drückt. Und im Prinzip sind "return, break, continue" ja auch goto's. ;-)

--Xato 21:21, 22. Mai 2007 (CEST)