Diskussion:C-Tutorial: Unterschied zwischen den Versionen

Version vom 26. Dezember 2005, 03:57 Uhr

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)