Hallo zusammen, Ich habe vor längerer Zeit ein paar Projekte mit "atmega's" gebastelt und in Basic programmiert. Mittlerweile habe ich aber wohl den Großteil vergessen :-) Jetzt habe ich wieder ein paar Ideen, möchte aber gern mit C beginnen. 1: Es gibt viele Bücher am Markt, könnt ihr eines für Einstiger empfehlen? 2: Gibt es einen Unterschied zwischen "C" und "C++"? Welche Sprache kommt denn hier zum Einsatz ? Danke !
Philipp L. schrieb: > 2: Gibt es einen Unterschied zwischen "C" und "C++"? Nein. Ist genau das gleiche. Deshalb gibt es zwei Bezeichnungen. Weil es absolut keinen Unterschied gibt.
Cyblord -. schrieb: > Philipp L. schrieb: > >> 2: Gibt es einen Unterschied zwischen "C" und "C++"? > > Nein. Ist genau das gleiche. Deshalb gibt es zwei Bezeichnungen. Weil es > absolut keinen Unterschied gibt. Etwas Ironie ist bei der Frage evtl. angebracht, aber bitte auf die ganze Frage Nr.2 antworten... Ich kenne den Unterschied nicht und würde gern wissen, in welche Richtung ich mich orientieren soll/muss. Daher ja auch der Emojy...
Cyblord -. schrieb: > Nein. Ist genau das gleiche. Deshalb gibt es zwei Bezeichnungen. Weil es > absolut keinen Unterschied gibt. CYBLORD, DEIN STIL STINKT UND GEFÄLLT DEN WENIGSTEN HIER: ÄNDERE DAS BALDMÖGLICHST!
Philipp L. schrieb: > 2: Gibt es einen Unterschied zwischen "C" und "C++"? > Welche Sprache kommt denn hier zum Einsatz ? Kommt darauf an, wo "hier" ist. Ist es in Controllern, dann ist es meistens C. Ansonsten ist C++ eine objektorientierte Sprache, im Gegensatz zu C. Das ist der eigentliche und wichtigste Unterschied, unterschiedliche Syntax (bzw. Erweiterungen bei C++) sind nur die Folge davon.
:
Bearbeitet durch User
Gastino G. schrieb: > Philipp L. schrieb: > >> 2: Gibt es einen Unterschied zwischen "C" und "C++"? >> Welche Sprache kommt denn hier zum Einsatz ? > > > Kommt darauf an, wo "hier" ist. Ist es in Controllern, dann ist es > meistens C. Ja, bei der Mikrocontrollerprogrammierung. Also hauptsächlich die Atmel-Familie (Mega und Tiny)
Klara N'sage schrieb: > Cyblord -. schrieb: >> Nein. Ist genau das gleiche. Deshalb gibt es zwei Bezeichnungen. Weil es >> absolut keinen Unterschied gibt. > > CYBLORD, DEIN STIL STINKT UND GEFÄLLT DEN WENIGSTEN HIER: ÄNDERE DAS > BALDMÖGLICHST! Nö, denn ich finde ihn voll supi.
Gastino G. schrieb: > Philipp L. schrieb: > >> 2: Gibt es einen Unterschied zwischen "C" und "C++"? >> Welche Sprache kommt denn hier zum Einsatz ? > > > Kommt darauf an, wo "hier" ist. Ist es in Controllern, dann ist es > meistens C. > > Ansonsten ist C++ eine objektorientierte Sprache, im Gegensatz zu C. Das > ist der eigentliche und wichtigste Unterschied, unterschiedliche Syntax > (bzw. Erweiterungen bei C++) sind nur die Folge davon. Sehr hilfreiche Antwort, danke ! Dann lautet die Frage also nur noch: Welche Einsteiger Bücher für die C Programmierung könnt ihr empfehlen?
Cyblord -. schrieb: > Nö, denn ich finde ihn voll supi. Nicht mehr lange, denn dann wird sein Account gesperrt, wegen penetranter Trollerei. ;-b
Es existieren für beide Sprachen Compiler, welche deinen Code für AVR kompilieren. Als Anfang kann ich dieses Buch: https://www.amazon.de/AVR-Mikrocontroller-Kochbuch-PC-Elektronik-Lukas-Salzburger/dp/3645651268 empfehlen. Es ist eine Einführung in Mikrocontroller anhand des Atmega 8 und gibt eine kleine Einführung in C, und das was relevant ist zur Mikrocontroller Programmierung. Mit C++ zu beginnen ist aus meiner Sicht aufwendiger, gibt dir aber auch mehr Möglichkeiten, da es zum Beispiel Objektorientierung unterstützt. C++ baut allerdings stark auf C auf, so dass man ziemlich schnell das in C gelernte auch in C++ hinbekommt. Willst du C++ lernen, kann ich dir dieses Buch empfehlen: https://www.pearson.ch/HigherEducation/PearsonStudium/EAN/9783868940053/Einfuehrung-in-die-Programmierung-mit-C Es ist vom Erfinder von C++ geschrieben worden.
Da hat sich wohl ein x durch ein Leerzeichen ersetzt. Korrekt wäre: AtmegaX8 (d.h. Atmega48, Atmega88,...)
trampi schrieb: > Es existieren für beide Sprachen Compiler, welche deinen Code für AVR > kompilieren. > Als Anfang kann ich dieses Buch: > > https://www.amazon.de/AVR-Mikrocontroller-Kochbuch-PC-Elektronik-Lukas-Salzburger/dp/3645651268 > > empfehlen. Es ist eine Einführung in Mikrocontroller anhand des Atmega 8 > und gibt eine kleine Einführung in C, und das was relevant ist zur > Mikrocontroller Programmierung. > Elekttonikkentnisse und grundlegende Erfahrungen mit den Controllern sind vorhanden. Es geht rein um die Umstellung der Programmiersprache von Basic (auch schon länger her) zu C.
Philipp L. schrieb: > Es geht rein um die Umstellung der Programmiersprache von Basic (auch > schon länger her) zu C. Dann wäre vielleicht dieses Tutorial (gibt es auch als Buch) etwas: http://www.schellong.de/c.htm Ich würde dir allerdings vorschlagen, einfach mal dem AVR-GCC-Tutorial zu folgen, wenn du schon etwas programmieren kannst (egal welche Sprache), solltest du ziemlich schnell die Grundlagen verstehen.
Hallo
"Jetzt habe ich wieder ein paar Ideen, möchte aber gern mit C beginnen"
Ähnliches habe ich auch mal vor gehabt - wenn du Bücher und Tutorials
suchst was dir C speziell für den Bereich µC (AVR) beibringt sieht es
leider schlecht aus - scheinbar bauen alle Bücher und Tutorials aus
diesen Umfeld darauf auf das du C mehr oder weniger schon beherrschst
und lassen sich dann nur noch über einige Besonderheiten im µC Bereich
aus - vor allem was die Hardware und deren Beschränkungen und
Andersartigkeit gegenüber einen normalen PC (Leistungsfähigen Endgerät)
angeht.
Eine ziemlich unzufriedene Situation für jemanden der aus der
Hardwareecke kommt ("alles" dort versteht) aber von Programmierung nur
wenig Ahnung hat.
Leider bleibt es dann doch bei den typischen Büchern und Kursen für den
PC (Endgeräte) wo man auf viel erlernt was im typischen 8Bit µC Bereich
(z.B. AVR) nur wenig Nutzen hat, dafür andere dort sehr wichtige
Themenbereiche oft nur relativ grob abgehandelt werden.
Datenbanken, alle möglichen Feinheiten der Text ein- und Ausgabe sind
beim 8Bit µC und den typischen Anwendungen kaum von Belang -
Bitmanipulation, direktes Arbeiten mit Registern, Modifizieren müssen
von Bibliotheken, Einbindung von einzelnen Assembler Befehlen oder gar
Codeabschnitten (und sei es nur ein nop) aber um so mehr - was ist nun
aber beim PC (Endgeräte)kaum ein Thema oder kommt sehr spät, und oft
schlecht erklärt, dran.
Die sehr wenigen Autoren (Bücher) die sich direkt ans Thema C für µC
(AVR) gewagt haben konnten alle nicht das liefern was ich (und wohl
jeder Anfänger) benötigt hätten - es bleibt leider nur der klassische
Weg über den PC mit all den "unnötigen" (Hobbybereich,
Hobbyanwendung)Ballast.
Jemand
Klara N'sage schrieb: > CYBLORD, DEIN STIL STINKT UND GEFÄLLT DEN WENIGSTEN HIER Sprich bitte nur für dich und maße dir nicht an, die Meinung Dritter zu kennen oder für sie zu äußern. Mir persönlich gehen unverschämte, anonyme Posts wie deiner viel mehr auf den Sack.
Beitrag #5688545 wurde von einem Moderator gelöscht.
Beitrag #5688559 wurde von einem Moderator gelöscht.
Cyblord -. schrieb: > Philipp L. schrieb: > >> 2: Gibt es einen Unterschied zwischen "C" und "C++"? > > Nein. Ist genau das gleiche. Deshalb gibt es zwei Bezeichnungen. Weil es > absolut keinen Unterschied gibt. Kann man aus solch erhaben und erhöhter Position nicht einfach mal schweigen? Oder - falls das folgende jetzt verständlicher ist - einfach mal die Fresse halten!
Walter K. schrieb: > Kann man aus solch erhaben und erhöhter Position nicht einfach mal > schweigen? Das wäre unfair. Je erhabener man ist, desto mehr ist man in der Pflicht die Unwissenden teilhaben zu lassen. Halleluja.
Axel S. schrieb: > Mir persönlich gehen unverschämte, > anonyme Posts wie deiner viel mehr auf den Sack. Die Frage ist jetzt wieviel weniger anonym ist für dich ein angemeldeter Benutzer? Und der Post von Cyblord war nicht mehr lustig sondern genauso unverschämt.
Als solide Grundlage würde ich den Klassiker von Ritchie Kernighan immer wieder empfehlen. Danach kommt dann das AVR-Spezifische an die Reihe. Da ich nicht regelmäßig programmiere, geraten auch schon mal die Basics in Vergessenheit. Zu jeder aufkommenden Frage habe ich bislang ziemlich schnell im Internet die passende Antwort gefunden ohne zum Buch zu greifen. C-Programmierung ist dank ihrer Verbreitung sehr gut dokumentiert.
trampi schrieb: > Dann wäre vielleicht dieses Tutorial (gibt es auch als Buch) etwas: > http://www.schellong.de/c.htm Von dem kann nur abgeraten werden. Der hat noch bizarrere Vorstellungen von C als die verschiedenen Chaoten, die hier jede Forendiskussion über Programmiersprachen mit ihrem Achtelwissen anreichern müssen.
Cyblord -. schrieb: > Das wäre unfair. Je erhabener man ist, desto mehr ist man in der Pflicht > die Unwissenden teilhaben zu lassen. Halleluja. ROFL, you made my day!
Hatten wir damals auf der Schule: https://www.amazon.de/C-Programmieren-Anfang-Helmut-Erlenk%C3%B6tter/dp/3499600749 Hab ich privat auch gelegentlich reingeschaut.
Beitrag #5688623 wurde von einem Moderator gelöscht.
Philipp L. schrieb: > 1: Es gibt viele Bücher am Markt, könnt ihr eines für Einstiger > empfehlen? Würde mit dem hier anfangen: http://c-buch.sommergut.de/ Eine gut strukturierte Anleitung das die Sprache gut erklärt.
trampi schrieb: > Dann wäre vielleicht dieses Tutorial (gibt es auch als Buch) etwas: > http://www.schellong.de/c.htm Soll das ein Einsteiger-Tutorial sein? Selbst erfahrene Programmierer dürften Schwierigkeiten haben durch diese wirre Fakten-Auflistung durchzublicken. Wie soll man da als Anfänger irgendwas verstehen...
Hi Da https://www.terrashop.de/buecher/fachbuch/computer/prog/c_c/ gibt es 109 Bücher zu C/C++ zu teilweise reduzierten Preisen. MfG Spess
Ich würde auch auf die "C-Bibel" von Kernighan/Ritchie zurückgreifen: The C Programming Language, aber bitte nur im englischen Original, denn die deutsche Übersetzung ist sowas von grausam. Generationen von Entwicklen haben mit diesem Werk ANSI-C gelernt (mich eingeschlossen) und dann solltest Du das auch schaffen! - Insbesondere erklärt es Spezialitäten von C sehr gut wie zum Beispiel der Unterschied zwischen Pointern und Integern, Pointer-Arithmetik, Unions usw. Wenn man das weitestgehend verinnerlicht hat, kann man zumindest erst einmal lauffähige Programme schreiben. Als Test-Entwicklungsumgebung würde ich einen Linux-PC mit einer GCC-Toolchain empfehlen. Damit kann man alle Beispiele des Buches durchprobieren. Wenn man dann etwas Erfahrung gesammelt hat, versuchst Du vielleicht einfach mal Dir andere C-Programme anzusehen und zu verstehen. Auch das Einbinden statischer oder dynamischer Bibliotheken ist interessant. Erst danach würde ich mich dem Mikrocontroller zuwenden, dazumal diese Plattformen in der Regel ein paar Einschränkungen und auch durchaus spezielle Syntax mitbringen. Sinnvollerweise ist der AVR-GCC eben auch ein GCC-Compiler (wie auf dem Linux-PC) und Du wirst damit recht gut zurechtkommen. Auch der XC8/XC16/XC32 von Microchip ist ein GCC, wie auch die vielen Toolchains für ARM. Wenn Du dann etwas erfahren bist, solltest Du Dich entsprechenden Coding-Richtlinien, C90/C99-Standard und deren Nachfolger beeschäftigen. So bewegst Du Dich vom ANSI-Standard etwas weg, was aber praktisch keine Relevanz hat, da alle wichtigen Controllern heutzutage irgendwie einen GCC-Compiler haben. Es gibt auch Ausnahmen wie zum Beispiel den Paradigm C-Compiler, den ich versuche zu vermeiden... Viel Glück! Sven
Udo S. schrieb: > Axel S. schrieb: >> Mir persönlich gehen unverschämte, >> anonyme Posts wie deiner viel mehr auf den Sack. > > Die Frage ist jetzt wieviel weniger anonym ist für dich ein angemeldeter > Benutzer? Ganz einfach. Ein angemeldeter Nenutzer kann sanktioniert werden, falls er sich hinreichend oft oder zu sehr daneben benimmt. Ein anonymer Poster nicht. Insbesondere gestehe ich einem anonymen Poster keinerlei Recht zu, Kritik am hier herrschenden Umgang zu äußern. Das darf er gern machen nachdem er sich angemeldet hat. Darüber hinaus war sein Post kein bißchen höflicher oder besser als der, den er kritisiert. Schon das nimmt ihm jegliche Legitimation. Sein Ziel war ganz offensichtlich nicht, den Umgangston hier zu verbessern. Er wollte einfach nur pöbeln. > Und der Post von Cyblord war nicht mehr lustig sondern genauso > unverschämt. Die Frage war vollkommen dämlich. Wer programmieren lernen will, aber nicht in der Lage ist, den Unterschied zwischen C und C++ herauszufinden, ist entweder grauenhaft dumm oder stinkend faul. Ich enthalte mich hier absichtlich einer näheren Bewertung.
Axel S. schrieb: > ist entweder grauenhaft dumm oder stinkend faul. Sorry aber das kann man nur noch als unsäglich arrogant bezeichnen.
Ich finde die Bücher von Rheinwerk ganz gut. Zum einen sind die auf deutsch, was es leichter macht, zum anderen gibt es die auch als Openbook. http://openbook.rheinwerk-verlag.de/c_von_a_bis_z/000_c_vorwort_001.htm#mj764cb3fd439d3b95d1843e7c7d17f235 Dann kann man von überall schnell was nachschlagen. Viel Spass!!! Sebastian
:
Bearbeitet durch User
Sebastian R. schrieb: > Ich finde die Bücher von Rheinwerk ganz gut. Das haben wir doch schon abgehandelt: Beitrag "C-Lehrbuch aus dem Rheinwerk-Verlag schlecht? Alternative?"
Rufus Τ. F. schrieb: > trampi schrieb: >> Dann wäre vielleicht dieses Tutorial (gibt es auch >> als Buch) etwas: http://www.schellong.de/c.htm > > Von dem kann nur abgeraten werden. Der hat noch bizarrere > Vorstellungen von C als die verschiedenen Chaoten, die > hier jede Forendiskussion über Programmiersprachen mit > ihrem Achtelwissen anreichern müssen. Ich habe selten eine substanzlosere und für den Kritiker beschämendere Kritik gelesen.
Dr. Sommer schrieb: > trampi schrieb: >> Dann wäre vielleicht dieses Tutorial (gibt es auch >> als Buch) etwas: http://www.schellong.de/c.htm > > Soll das ein Einsteiger-Tutorial sein? Selbst erfahrene > Programmierer dürften Schwierigkeiten haben durch diese > wirre Fakten-Auflistung durchzublicken. Wie soll man da > als Anfänger irgendwas verstehen... Tja... das ist der Lauf der Welt: Was sich die erste Generation noch unter unsäglichen Mühen mit Blut, Schweiss und Tränen bitter erarbeitet hat, ist dann für die zweite oder dritte Generation nur noch ein Vierteljahreskurs an der höheren Töchterschule. Tragisch, aber unvermeidlich...
voltwide schrieb: > Als solide Grundlage würde ich den Klassiker von Ritchie Kernighan immer > wieder empfehlen. Das ist didaktisch ähnlich gut geeignet wie eine DIN-Norm als Technik-Lehrbuch. Warum gibt es wohl so viele Lehrbücher aus anderer Quelle?
Egon D. schrieb: > Was sich die erste Generation noch unter unsäglichen Mühen mit Blut, > Schweiss und Tränen bitter erarbeitet hat, Oh weia. Ruhe dich mal nicht zu sehr auf deinen Lorbeeren aus. Warum sollte man unbedingt mit so einem Text arbeiten, wenn selbst das allererste Buch über C - das von K&R - besser ist?
Dr. Sommer schrieb: > Egon D. schrieb: >> Was sich die erste Generation noch unter unsäglichen >> Mühen mit Blut, Schweiss und Tränen bitter erarbeitet >> hat, > > Oh weia. Ruhe dich mal nicht zu sehr auf deinen Lorbeeren > aus. Oh tempora, oh mores. Nicht einmal Zynismus wird noch verstanden. Es sind nicht MEINE Lorbeeren (ich kann kein C), sondern allenfalls Rufus' und Deine. (Anders kann ich mir jedenfalls Eure blinde Ablehnung nicht erklären.) > Warum sollte man unbedingt mit so einem Text arbeiten, > wenn selbst das allererste Buch über C - das von K&R - > besser ist? Weil es (=K&R) nur in den Augen völlig betriebsblinder "erfahrener C-Programmierer" besser ist. Viele Eigenheiten von C sind nur aus dem historischen Kontext verständlich. Der K&R ist sehr interessant, aber eben auch genau das: Ein historisches Dokument. Ich erlaube mir dieses Urteil, weil ich im Moment in meinem inzwischen 3. Anlauf stecke, die Programmiersprache C zu erlernen, und das natürlich -- wie wohl jeder dumme Anfänger -- mit dem K&R versucht habe. Zum Glück ist mir bald aufgefallen, dass der K&R für diesen Zweck untauglich ist, und ich habe begonnen, mir eigene Unterlagen zu erarbeiten. Diese kommen -- wer hätte das jetzt gedacht! -- in ihrer Struktur dem Kurs von Helmut S. ziemlich nahe...
Egon D. schrieb: > Ich habe selten eine substanzlosere und für den Kritiker > beschämendere Kritik gelesen. Ach was, in diesem Punkte hat der Rufus völlig Recht. Wer sich mal den Anfang dieses Buches anschaut, sieht die typischen Mißgriffe: [Zitat] C-Programm, C-Module/Dateien, C-Quellkode, Compiler Ein C-Programm besteht aus einer oder mehreren Datei(en) mit der Endung .c , aus der/denen ein C-Compiler eine ausführbare Datei (oftmals mit der Endung .exe) erzeugt. Eine C-Datei (oder auch C-Modul) wird mit einem beliebigen Text-Editor erzeugt und muß gültigen C-Quellkode enthalten. Der Aufruf-Name eines C-Compilers lautet vom Unix-Ursprung her: cc 'cc' ist aber nicht der eigentliche Compiler, sondern nur ein Manager-Programm (Frontend), das die angegebenen Argumente prüft und die diversen Programme des Entwicklungssystems (oft mit vielen zusätzlichen Argumenten) jeweils in der richtigen Reihenfolge korrekt aufruft. Verschiedene Aufruf-Namen: cc (Unix-Standard), bcc (Borland/DOS), cl (Microsoft/DOS), gcc (Gnu/Unix), CC (C++/Unix), ... [/Zitat] .. na und so weiter. Jahaha! Wer hätte das gedacht, daß eine C Datei tatsächlich gültigen C-Quellcode enthalten sollte! Das ist ja wirklich UNGLAUBLICH.. wenn's hier nicht explizit geschrieben worden wäre. Aber die anderen Schreiberlinge kommen mir da auch nicht wirklich ungeschoren davon. Hier etwas von Rheinwerk: [Zitat] Um zu verstehen, warum in C ein Standard eingeführt wurde, müssen Sie etwas zur Geschichte dieser Sprache wissen. 1 Einstieg in C 1.1 Übersicht zu C Mit C lernen Sie eine Programmiersprache, die auf fast allen Betriebssystemen zur Verfügung steht. Besser noch, anders als bei vielen anderen Sprachen (beispielsweise BASIC) steht Ihnen auf den verschiedensten Plattformen eine genormte Standard-C-Bibliothek zur Verfügung. Dank dieser einheitlichen Implementierung und der sehr guten Geschwindigkeit der damit erstellten Programme ist und bleibt C wohl noch für eine sehr lange Zeit eine sehr populäre Sprache – und das sowohl im kommerziellen als auch (vor allem) im Open-Source-Bereich. C wird auch liebevoll als High-Level-Assembler bezeichnet. Dies resultiert auch daher, dass der Kern (besser bekannt als Kernel) aller gängigen Betriebssysteme in C (und natürlich Assembler) geschrieben wurde – weshalb sich C hervorragend zur Systemprogrammierung eignet. [/Zitat] Also, in was für einem Kindergarten sind wir hier eigentlich? Oder in was für einer verunglückten Werbeabteilung? Unter obigem 1.1 hätte ich anstelle der Werbung eher mich über die Grundsätze ausgelassen, also - daß man zum Schreiben von C-Quellen einen Editor nimmt und nicht Word. - daß C formatfrei geschrieben wird, also daß man nicht an bestimmte Zeilen- und Spaltennummern gebunden ist und Anweisungen auch über mehrere Zeile gehen dürfen - daß der zu verwendende Zeichenvorrat aus ASCII besteht und daß C im allgemeinen Case-sensitiv ist und so weiter. Eben so, daß man von Grund auf die Dinge abklärt, die in dieser Sprache erforderlich sind. Aber offenbar können alle eingefleischten C-Programmierer nur neben allgemeinem Gesülze sofort in irgenwelche speziellen Nebensächlichkeiten verfallen und sich dort auslabern. Wahrscheinlich müßte man all diese Leute mit dem Prügel dazu zwingen, ihr Thema zuvörderst in Backus-Naur-Form niederzuschreiben - damit sie wenigstens eine vage Vorstellung von Systematik bekommen. Meine Erfahrung: So richtig gute Einführungen in C gibt es nicht. W.S.
Egon D. schrieb: > Es sind nicht MEINE Lorbeeren Diese Logik ist mir zu verschachtelt... Egon D. schrieb: > Diese kommen -- wer hätte das jetzt gedacht! -- in ihrer Struktur dem > Kurs von Helmut S. ziemlich nahe... Weil die eigenen Notizen eher Referenzcharakter haben; ein Einsteigerbuch eher nicht. Oder liest du auch Lexika von A-Z?
Sven L. schrieb: > Ich würde auch auf die "C-Bibel" von Kernighan/Ritchie zurückgreifen: > The C Programming Language, aber bitte nur im englischen Original, denn > die deutsche Übersetzung ist sowas von grausam. Wenn Du die erste Ausgabe meinst, bin ich, was die Übersetzung betrifft, auf Deiner Seite, diese Ausgabe ist wirklich grauenerregend. Allerdings beschreibt sie den antiquarischen C-Standard vor ANSI-C, halt das alte "K&R"-C, das keine Funktionsprototypen kennt und daher bei Funktionsaufrufen keinerlei Typprüfungen durchführen kann. Die zweite Ausgabe hingegen, die "ANSI-C" bzw. C89 beschreibt, ist auch in der deutschen Übersetzung durchaus brauchbar. Und eine neuere Ausgabe gibt es nicht. Egon D. schrieb: > Zum Glück ist mir bald aufgefallen, dass der K&R für diesen Zweck > untauglich ist Ich habe selten eine substanzlosere und für den Kritiker beschämendere Kritik gelesen.
Für einen schnellen Einblick zum Vergleichen bietet sich das Erlenkötter-C-Buch und die (recht neue) Tour of C++ von Bjarne Stroustrup an, zumindest, wenn man schon (mehr oder weniger) programmieren kann. K&R-C ist Lernen von den Profis, bzw. von den Besten, das muss nicht für jeden gleich genießbar sein. Der Erlenkötter ist aber besser geeignet, um schnell bestimmte C-Code-Muster zu verstehen während in K&R das Referenz+Nachschlagewerk zu sehen ist. Groß auf den Zusammenhang der Codebeispiele einzugehen (wozu?, RealWorld?) vermeiden beide Bücher. Das war früher eigentlich anders: ganze (gut gemachte) Zeitschriftenartikel über z.B. Halltheorien oder Filter und deren Implementierungansatz UND auch noch üppige Code-Beispiele bzw. Programmieranleitungen zum Abtippen (damals meist in Basic). In der Schule: coole Wahrscheinlichkeitsberechnungsprogramme, Wertetabellen, Analysis, Dies und Das + Kaspereien .. (man müsste sich ein paar alte Artikel aus früheren Zeitschriften besorgen und die Programmcodes von Basic nach C bzw. C++ übersetzen)
Rufus Τ. F. schrieb: > Egon D. schrieb: >> Zum Glück ist mir bald aufgefallen, dass der K&R für >> diesen Zweck untauglich ist > > Ich habe selten eine substanzlosere und für den Kritiker > beschämendere Kritik gelesen. Sicher nicht. Ich habe nämlich -- im Gegensatz zu Dir -- nicht davon gesprochen, das die Herren Kernighan und Ritchie "bizarre Vorstellungen" hätten, die man mit den Ideen von "Chaoten" auf eine Stufe stellen könnte, die ihr "Achtelwissen" zur Schau stellen. Vielleicht beginnst Du IRGENDWANN einmal, Deine Moderatorentätigkeit nicht nur als probate Möglichkeit zur Machtausübung, sondern als VERPFLICHTUNG zu einer Vorbildrolle zu verstehen.
Sicher ist mein Beitrag, der an Wahrhaftigkeit deem Beitrag eines "Cyblords" oder eines "A-Z, 0-9" nicht nachsteht, nur versehentlich gelöscht worden. Das macht nichts, denn ich habe ein so gutes Gedächtnis, daß ich ihn stets und ständig wortgetreu wiederholen kann (und werde)! Cerberus schrieb: > Cyblord -. schrieb: >> Nö, denn ich finde ihn voll supi. > > Nicht mehr lange, denn dann wird sein Account gesperrt, > wegen penetranter Trollerei. ;-b Das glaubst Du doch selbst nicht. Der ist hier als Agent Provocateur fest eingestellt. Der hier ist das gleiche Kaliber: > CYBLORD, DEIN STIL STINKT UND GEFÄLLT DEN WENIGSTEN HIER >> Sprich bitte nur für dich und maße dir nicht an, die Meinung Dritter zu >> kennen oder für sie zu äußern. Mir persönlich gehen unverschämte, >> anonyme Posts wie deiner viel mehr auf den Sack. Das ganze Forum stinkt Dank solcher unsauberen Figuren.
Ich fand "Head First C" ganz nett - wenn man die "Brain Friendly Guide"-Serie mag. Und dann direkt "C Traps and Pitfalls" von Andrew Koenig nachlegen. Dass man mir im Forum hier immer wieder nahelegt, ich solle "ein Buch kaufen und C lernen", liegt nicht daran, daß die Bücher so schlecht sind, sondern daß ich so dumm bin. Wie für die meisten Lehrbücher gilt: Wenn man mit Englisch kein Problem hat, ist die englische Version gegenüber der deutschen Übersetzung zu bevorzugen, da sowohl besser als auch billiger.
:
Bearbeitet durch User
Dr. Sommer schrieb: > Egon D. schrieb: >> Diese kommen -- wer hätte das jetzt gedacht! -- in ihrer >> Struktur dem Kurs von Helmut S. ziemlich nahe... > > Weil die eigenen Notizen eher Referenzcharakter haben; Nö. Meine nicht. Ich versuche, eine Art Repetitorium zu verfassen. Das baut natürlich auf meinem persönlichen Vorwissen auf und versucht, den Stoff so darzustellen, dass jemand, der grundlegend programmieren kann und weiss, wie Computer funktionieren, leicht die Besonderheiten von C erkennen kann. Das betrifft eher die Gliederung und Gruppierung des Stoffes und weniger die formalen Details. Das genaue "Wie" muss man notfalls im Standard nachschlagen. Für den Anfänger wichtig ist eher die Frage "Warum?" Warum wurde dies von den Sprachschöpfern gerade SO und nicht anders festgelegt? > Oder liest du auch Lexika von A-Z? Nein, natürlich nicht -- aber das hat doch nichts mit dem Thema zu tun?! K&R waren dem Geist ihrer Zeit verhaftet. Das ist überhaupt keine Herabsetzung, sondern nur eine Feststellung. Da sich die Zeiten geändert und sich die Prioritäten verschoben haben, ist eine geänderte Darstellung notwendig. Mich als Anfänger interessieren nicht die Bohne die subtilen Unterschiede, wo ich unbedingt geschweifte Klammern setzen muss , wo es nur empfehlenswert ist, und wo ich sie weglassen kann . Das ist in einer Spracheinführung komplette Zeitverschwendung. Ich brauche EIN System (und zwar ein EINFACHES System), das Fehlerarmut garantiert und unliebsame Überraschungen weitgehend ausschließt. Das nur als Beispiel; es gibt noch viele andere solcher Punkte.
Egon D. schrieb: > Nein, natürlich nicht -- aber das hat doch nichts mit dem Thema zu tun?! Das Schellong-buch ist aber so geschrieben. Es werden einem eine Reihe an C Konstrukten um die Ohren geknallt ohne sie vernünftig in einen Kontext zu bringen. Vernünftige Bücher erläutern erst die Umsetzung einfacher Programme und steigern sich dann, und zeigen dabei die benutzten Mechanismen. Das erste Beispiel im Schellong Buch ist schon so lang dass das kein Anfänger versteht, und erklärt wird nix.
Ich hab' das Gefühl, daß Du mit der "Lernbetty" von W.S. glücklich werden könntest.
Molluske schrieb: > C++ ist tot, es lebe Rust. Nein, wenn schon, dann Haskell. Das hat verschiedene Gründe. Man denkt sich aber: irgendwann ist irgendwann zu spät..:(
Rufus Τ. F. schrieb: > Ich hab' das Gefühl, daß Du mit der "Lernbetty" von W.S. glücklich > werden könntest. Bei der krieg ich Ausschlag wenn ich den Programmierstil sehe. Die kann man als Negativbeispiel nutzen, wie man es nicht machen sollte...
Dr. Sommer schrieb: > Bei der krieg ich Ausschlag wenn ich den Programmierstil sehe. Den bekomme ich da auch - und beim Schellong. Da der so begeistert aufgenommen wird, denke ich mir, daß das zusammen passen dürfte.
W.S. schrieb: > Unter obigem 1.1 hätte ich anstelle der Werbung eher > mich über die Grundsätze ausgelassen, also > - daß man zum Schreiben von C-Quellen einen Editor nimmt > und nicht Word. > - daß C formatfrei geschrieben wird, also daß man nicht > an bestimmte Zeilen- und Spaltennummern gebunden ist > und Anweisungen auch über mehrere Zeile gehen dürfen > - daß der zu verwendende Zeichenvorrat aus ASCII besteht > und daß C im allgemeinen Case-sensitiv ist > > und so weiter. Eben so, daß man von Grund auf die Dinge > abklärt, die in dieser Sprache erforderlich sind. Richtig. In meinen privaten Notizen steht das auch ungefähr so :) > Aber offenbar können alle eingefleischten C-Programmierer > nur neben allgemeinem Gesülze sofort in irgenwelche > speziellen Nebensächlichkeiten verfallen und sich dort > auslabern. Ahh. Hier wird W.S. wieder der alte... die Sachlichkeit war ja schon angsteinflößend... > Wahrscheinlich müßte man all diese Leute mit dem Prügel > dazu zwingen, ihr Thema zuvörderst in Backus-Naur-Form > niederzuschreiben - damit sie wenigstens eine vage > Vorstellung von Systematik bekommen. Du hast Recht -- aber hasserfüllte Diffamierungen der Autoren führen nicht weiter. Das spannende Rätsel ist: WARUM ist das so? Welcher Einfluss in der Ausbildung oder in der alltäglichen Tätigkeit der Informatiker führt dazu, dass sie zwar komplexe Strukturen verstehen, schaffen und verbessern können -- diesen Prozess selbst aber nicht wohlstrukturiert erklären können? > Meine Erfahrung: So richtig gute Einführungen in C gibt > es nicht. Mag sein. Die Art, wie Helmut S. den Stoff gliedert, gefällt mir schon mal.
Egon D. schrieb: > Mag sein. Die Art, wie Helmut S. den Stoff gliedert, gefällt mir schon > mal. Ernsthaft? Wie viele der Kapitel musstest du denn lesen um ein Hello World zu schreiben... und auch zu wissen was die einzelnen Wörter bedeuten? Direkt das erste Beispiel enthält das Wort "register". Hast du das sofort verstanden? Würde es jemand verstehen der noch nie programmiert hat und keine Ahnung hat wie eine CPU aufgebaut ist? Eines der ersten Beispiele benutzt setjmp. War das auch sofort einsichtig? Egon D. schrieb: > Welcher Einfluss in der Ausbildung oder in der alltäglichen Tätigkeit > der Informatiker führt dazu, dass sie zwar komplexe Strukturen > verstehen, schaffen und verbessern können -- diesen Prozess selbst aber > nicht wohlstrukturiert erklären können? Weil die Denk-Strukturen zur Anwendung andere sind als zum Erklären. Ist z.B. bei Mathematikern auch so. Etwas das einem Experten völlig klar ist kann einem Anfänger große Verständnisprobleme bedeuten; das zu erklären ist dann schwierig. Man sieht dem Wald einfach nicht mehr. Daher sind gute Professoren auch rar.
Dr. Sommer schrieb: > Das Schellong-buch ist aber so geschrieben. Es werden einem eine Reihe > an C Konstrukten um die Ohren geknallt ohne sie vernünftig in einen > Kontext zu bringen. Dabei sollte man nicht vergessen, dass der Teil im Internet nur die zur Referenz komprimierte Fassung des Buches ist. Das Buch ist selbst wesentlich umfangreicher. Mir gefällt es, wie vieles aber Geschmackssache. Jens
Jens schrieb: > Das Buch ist selbst wesentlich umfangreicher. Achso. Dann ist es ja nicht so schlimm.
Dr. Sommer schrieb: > Egon D. schrieb: >> Nein, natürlich nicht -- aber das hat doch nichts >> mit dem Thema zu tun?! > > Das Schellong-buch ist aber so geschrieben. Wie "SO"? Wie ein Lexikon? > Es werden einem eine Reihe an C Konstrukten um die > Ohren geknallt ohne sie vernünftig in einen Kontext > zu bringen. Nun ja, eine der herausragenden Eigenheiten von C ist, dass unheimlich viel "Funktionalität" in verhältnismäßig wenig "Sprache" gequetscht wurde. Das ist vom heutigen Standpunkt aus lästig, ist aber dem damaligen Stand der Technik geschuldet. Man sollte also, um einen Spruch von Lem hier anzubringen, "...weder lieben noch hassen, sondern verstehen." Etwas drastischer ausgedrückt: Eine konsistente Logik in etwas aufzeigen zu wollen, das keine konsistente Logik HAT , ist Zeitverschwendung. C ist ein wildes Konglomerat ausgeklügelter, aber im Prinzip willkürlicher Festlegungen. Ich leugne die Genialität gar nicht, die dahintersteckt -- aber man sollte auch nicht mehr Bedeutung hineininterpretieren, als es enthält. > Vernünftige Bücher erläutern erst die Umsetzung > einfacher Programme und steigern sich dann, und > zeigen dabei die benutzten Mechanismen. Nein -- wozu? Wenn ich auf die Schnelle ein Programm hinrotzen will, das halbwegs läuft, nehme ich Tcl. Wenn ich dann noch will, dass es SCHNELL AUSGEFÜHRT wird, nehme ich FreePascal. Wer C lernt, hat also ein spezielles Motiv, genau C zu lernen -- und nicht eine Sprache, die etwas weniger wählerisch bei der Auswahl ihrer Freunde ist. Und wer dieses spezielle Motiv hat, dem muss man nicht mehr erklären, dass Computer mit Nullen und Einsen funktionieren. Das Problem an den Einführungsbüchern ist, dass immer vorausgesetzt wird, der Leser habe nicht die geringste Ahnung von COMPUTERN. Das ist aber idiotisch -- sehr oft ist es so, dass der Leser nur keine Ahung von genau DIESER PROGRAMMIERSPRACHE hat, sich aber sehr wohl mit Computern einigermaßen auskennt! > Das erste Beispiel im Schellong Buch ist schon so > lang dass das kein Anfänger versteht, und erklärt > wird nix. Kann sein. Meine Aussage ist nicht, dass das Buch super ist, sondern nur, dass die Grundidee meiner Meinung nach in die richtige Richtung geht.
Egon D. schrieb: > Nein -- wozu? Um eine stetige Lernkurve zu erhalten. Viele Informatiker sind Learning By Doing Menschen und probieren gerne alles sofort aus. Wenn man erst das ganze Buch lesen muss um das simpelste Hello World schreiben zu können weil "puts" unter "P" zu finden ist wie im Lexikon, geht das nicht. Egon D. schrieb: > Das ist aber idiotisch -- sehr oft ist es so, dass der Leser nur keine > Ahung von genau DIESER PROGRAMMIERSPRACHE hat, sich aber sehr wohl mit > Computern einigermaßen auskennt! Daher muss das Buch aber trotzdem nicht so mies strukturiert sein. z.B. "The rust programming language" fängt auch mit einem Hello World an und steigert langsam die Komplexität, setzt aber voraus dass man schon programmieren kann. Das lässt sich sehr gut lesen. Man kann direkt nach den ersten paar Seiten eigene Programme schreiben, Konstrukte kombinieren und ihre Funktion erleben.
Bei java ist es doch noch schlimmer.
1 | public class Hallo |
2 | {
|
3 | public static void main( String[] args ){ |
4 | System.out.println( "Hallo, Welt!" ); |
5 | }
|
6 | |
7 | }
|
Muss man erst mal die Grundlagen von OOP beherrschen um "hallo" in der Console auszugeben? die C-Tutorials / Bücher setzen da wesentlich weniger Vorwissen voraus (behaupte ich mal)
Egon D. schrieb: > Welcher Einfluss in der Ausbildung oder in der alltäglichen > Tätigkeit der Informatiker führt dazu, dass sie zwar > komplexe Strukturen verstehen, schaffen und verbessern > können -- diesen Prozess selbst aber nicht wohlstrukturiert > erklären können? "Die vier Stufen der Kompetenzentwicklung" kannst du dir von Wikipeter erklären lassen... https://de.wikipedia.org/wiki/Kompetenzstufenentwicklung
zitter_ned_aso schrieb: > Muss man erst mal die Grundlagen von OOP beherrschen um "hallo" in der > Console auszugeben? Gar nicht so verkehrt, direkt Objekte zu erläutern. Diese Denkweise ist sehr verbreitet zur Strukturierung von Anwendungen. Das ist durchaus etwas, das C-programmierern fehlt. PS: so genial ist C auch nicht. Da gibt's viel lustigere Dinge :)
... wie immer viel gelaber von ahnungslosen! allgemein gibt es in dt/engl. zur soliden einführung in C alles ganz gut im netz! und zur vertiefung - must read! - Moderne C-Programmierung, H. Schellong - 21st Century C, Klemens alle guten c-bookz sind im web als pdf findbar! UND IMMER UND IMMER c-quellen studieren, ~80% sind trivial ABER die anderen 20% sind für die snippet schatztruhe, äh der hier allgemein gezeigte code ist oft zu 98-99,999% müll! mt
Dr. Sommer schrieb: > Gar nicht so verkehrt, direkt Objekte zu erläutern. Eher schreiben sie dann "erst mal so übernehmen, später wird es ausführlich erläutert". Dafür hat man dann bei Java-Büchern auf der Seite 573 eine GUI erstellt. Bei C++-Büchern bekommt man auf der Seite 875 den Hinweis dass es noch STL gibt. Aber dieses Thema kann hier nicht behandelt werden (da zu umfangreich und würde den Umfang dieses Einführungsbuches zu C++ mit 913 Seiten sprengen). Ich denke es ist OK, dass man am Anfang des Buches Begriffe verwendet, die noch nicht so klar sind. Weil man Fachbücher mehrmals liest. (und jedesmal entdeckt dabei etwas neues) Was ich viel wichtiger finde, sind die Aufgaben. (viellicht sogar mit Lösungen)
Dr. Sommer schrieb: > Egon D. schrieb: >> Mag sein. Die Art, wie Helmut S. den Stoff gliedert, >> gefällt mir schon mal. > > Ernsthaft? Ja, klar. Der Grund ist auch ganz einfach: Als ich vor einer Weile angefangen habe, C zu lernen, habe ich ziemlich ratlos vor dem K&R und einem Sammelsurium von Tutorials aus dem Internet gesessen und wusste nicht recht, wo ich anfangen sollte. Also habe ich versucht, mir anhand des K&R einen Überblick über den Lernstoff zu verschaffen. Bald kam die Idee auf, zuerst alles abzuhandeln, was mit dem Programmablauf selbst zu tun hat (Anweisungen und die Steuerstrukturen), um dann anhand einfacher Beispiele in das Typsystem einzudringen. (Das war deshalb naheliegend, weil die PASCAL-Bücher aus meiner frühen Jugend genauso aufgebaut waren.) Diese Reihenfolge funktioniert aber nicht, weil im ganzen K&R keine eindeutige Definition für Anweisungen zu finden ist -- was seine logische Erklärung darin findet, dass Anweisungen dadurch gebildet werden, dass einem Ausdruck ein Semikolons angefügt wird. Also muss man zuerst Ausdrücke abhandeln, ehe man Anweisungen betrachten kann. Ausdrücke bestehen aber aus Operatoren und Operanden. Operanden können Variablen, Konstanten (oder andere Ausdrücke) sein. Resultat: Man muss sich ERST mit dem ganzen Chaos des Typsystems und der fünfzehn Vorrangebenen der Operatoren herumärgern, ehe man den eigentlich ganz einfachen Teil der Steuerstruktur bearbeiten kann -- zumindest dann, wenn man den Stoff so aufbauen will, dass das Neue stets auf der Basis des schon Behandelten erklärt wird. > Wie viele der Kapitel musstest du denn lesen um ein > Hello World zu schreiben... und auch zu wissen was die > einzelnen Wörter bedeuten? Weisst Du was? Das ist mir komplett egal. Ich bin kein Fünfjähriger, der durch besonders lust- und erfolgsbetonte Didaktik bei der Stange gehalten werden muss. Ich habe mir vorgenommen, C zu lernen, weil ich Mikro- controller programmieren will und es dafür keine für mich akzeptable alternative Sprache gibt. Und ich habe den Anspruch an meine Arbeit, dass ich den Teil der Sprache, den ich aktiv einsetze, vollständig und richtig beherrsche. Mich interessiert -- wie bereits anderswo geschrieben -- nicht die Bohne, ob ich diese Klammer in jenem Spezialfall weglassen kann, sondern mich interessiert für den Anfang EIN Strickmuster, das möglichst frei von unerwarteten Nebenwirkungen und Fallstricken ist. Ich will nach Möglichkeit nichts Falsches lernen, weil Umlernen viel schwerer ist als Neulernen (und mit fast 50 Jahren hat man zum Umlernen nicht mehr SO viel Zeit). Ergo muss ich SEHR vorsichtig vorgehen und alles, was ich mir einbläue, SEHR sorgfältig prüfen. Es kommt dabei auf einen Monat mehr oder weniger überhaupt nicht an -- die Hauptsache ist VERLÄSSLICHES Wissen. Das ist aber mit Beispielen schlecht zu erreichen -- wichtig ist das tiefe Verständnis dafür, WARUM dieser Sachverhalt gerade SO und nicht anders festgelegt wurde. > Direkt das erste Beispiel enthält das Wort "register". > Hast du das sofort verstanden? Nein. Ich habe mir, um überhaupt irgendwie anzufangen, eine Übersicht der Schlüsselworten von ANSI-C aufgestellt (es sind genau 32), und diese, nach Themen gruppiert, auswendig gelernt. (Dabei macht man dann schon mal die anekdotische Beobachtung, dass das Typsystem doppelt soviel Raum einnimmt wie die Steueranweisungen.) Der nächste Schritt war, eine Tabelle aller Operatoren und des Vorranges aufzuschreiben und diese nach Anwendung zu gruppieren. Ich weiss inzwischen, dass es 15 Vorrangebenen und ca. 50 Operatoren gibt, aber ich kann sie noch nicht alle auswendig :) Was der dritte Schritt wird, weiss ich noch nicht. > Würde es jemand verstehen der noch nie programmiert > hat und keine Ahnung hat wie eine CPU aufgebaut ist? Das ist doch völlig irrelevant. Warum konstruierst Du einen hypothetischen C-Anfänger, wenn Dir hier ein realer C-Anfänger gegenübersitzt? Ich HABE schon programmiert. Ich WEISS, wie eine CPU aufgebaut ist. Und gestützt auf genau dieses Vorwissen will ich jetzt C lernen! > Eines der ersten Beispiele benutzt setjmp. War das > auch sofort einsichtig? Nein -- aber das ist doch irrelevant! Was habe ich denn von schnell angeeignetem Wissen, das mir zu schnellen "Erfolgen" verhilft, wenn die Hälfte dieses Wissens unvollständig und fehlerhaft ist? Überspitzt gesagt: Ich möchte vermeiden, dass die Besserwissen aus dem Mikroconrollerforum, die dann zukünftig an meinem C-Code herummäkeln, bei ihrer Mäkelei auch noch Recht haben! Das Ziel erreiche ich aber nicht, indem ich meterweise nur halb verstandene Sprachkonstrukte zusammennagele -- dazu enthält C viel zu viele Sprengfallen. > Egon D. schrieb: >> Welcher Einfluss in der Ausbildung oder in der >> alltäglichen Tätigkeit der Informatiker führt dazu, >> dass sie zwar komplexe Strukturen verstehen, schaffen >> und verbessern können -- diesen Prozess selbst aber >> nicht wohlstrukturiert erklären können? > > Weil die Denk-Strukturen zur Anwendung andere sind als > zum Erklären. Auf den ersten Blick ist das klar und scheinbar trivial. Auf den zweiten Blick bemerkt man dann, dass Programmierer ständig damit zu tun haben, reale Dinge zu abstrahieren und in abstrakter(er) Form zu beschreiben. Es überrascht mich daher schon, dass ihnen die umgekehrte Richtung -- nämlich allgemeinverständlich zu bechreiben, was sie auf der abstrakten Ebene eigentlich tun -- häufig SO schwer fällt.
Egon D. schrieb: > Auf den ersten Blick ist das klar und scheinbar trivial. > Auf den zweiten Blick bemerkt man dann, dass Programmierer > ständig damit zu tun haben, reale Dinge zu abstrahieren > und in abstrakter(er) Form zu beschreiben. > Es überrascht mich daher schon, dass ihnen die umgekehrte > Richtung -- nämlich allgemeinverständlich zu bechreiben, > was sie auf der abstrakten Ebene eigentlich tun -- häufig > SO schwer fällt. Daneben verwundert mich immer wieder, welche Schwierigkeiten manche Programmierer mit der deutschen Rechtschreibung und Grammatik zu haben scheinen; wenn sich dazwischen noch ein bisschen nachvollziehbare Semantik dekodieren lässt, darf man von Glück reden.
Nicht schlecht. Insgesamt werden im ganzen Thread fünf Bücher erwähnt, aber die Diskussion dreht sich jetzt zehn Scroll-Seiten darum, warum zwei davon schlecht seien. Offensichtlich ist es deutlich wichtiger, den blöden Anfängern klar zu machen, warum dieses oder jenes Buch schlecht ist, als zu erklären, was an bestimmten Büchern gut ist.
Walter T. schrieb: > Nicht schlecht. Insgesamt werden im ganzen Thread > fünf Bücher erwähnt, aber die Diskussion dreht sich > jetzt zehn Scroll-Seiten darum, warum zwei davon > schlecht seien. Naja, die Diskussion kann nicht besser sein als die Teilnehmer. Überdies gefällt mir Deine Wertung "schlecht" nicht so besonders. K&R ist nicht schlecht. Euklids "Elemente" sind auch nicht schlecht, aber trotzdem nicht zwingend die optimale Einsteigerliteratur. Dasselbe trifft auf das Rechenbuch von Adam Ries zu. > Offensichtlich ist es deutlich wichtiger, den blöden > Anfängern Ich bin zwar Anfänger, aber ich würde es nett finden, wenn Du mich trotzdem nicht als "blöd" beleidigen würdest. > klar zu machen, warum dieses oder jenes Buch > schlecht ist, als zu erklären, was an bestimmten > Büchern gut ist. Dann hast Du zumindest meinen langen Beitrag nicht (aufmerksam) gelesen, denn die ersten vier Absätze erklären, warum ich die inhaltliche Gliederung des Schellong-Buches gut finde: Sie entspricht genau dem Zugang zum Stoff, den ich selbst gewählt habe.
zitter_ned_aso schrieb: > Muss man erst mal die Grundlagen von OOP > beherrschen um "hallo" in der Console auszugeben? Wenn man eine objektoriente Sprache verwendet: Natürlich. Wie denn sonst? Man sollte ja auch die Grundlagen der Zerspanung beherrschen, wenn ohne Gefahr für Leib und Leben ein Stück Ding planfräsen will. Wie denn auch anders? > die C-Tutorials / Bücher setzen da wesentlich weniger > Vorwissen voraus (behaupte ich mal) Mag sein. Die Frage ist, ob das sinnvoll ist. Würdest Du Dich von einem Arzt operieren lassen, der lediglich "Hirnchirurgie für Dummies" gelesen hat?
Hallo zusammen, das ist ja ein ganz lebhafter Thread geworden :-) Vielen Dank !
Egon D. schrieb: >> Wahrscheinlich müßte man all diese Leute mit dem Prügel >> dazu zwingen, ihr Thema zuvörderst in Backus-Naur-Form >> niederzuschreiben - damit sie wenigstens eine vage >> Vorstellung von Systematik bekommen. > > Du hast Recht -- aber hasserfüllte Diffamierungen der > Autoren führen nicht weiter. > Das spannende Rätsel ist: WARUM ist das so? > > Welcher Einfluss in der Ausbildung oder in der alltäglichen > Tätigkeit der Informatiker führt dazu, dass sie zwar > komplexe Strukturen verstehen, schaffen und verbessern > können -- diesen Prozess selbst aber nicht wohlstrukturiert > erklären können? Nun, ich bin weder hasserfüllt (das hast du bloß hineininterpretiert) noch ist das eine Diffamierung geswesen. Es war nur eine Idee, den Chaoten, die nicht logisch denken können und deshalb auch keine sinnvoll aufgebauten Einführungen in eine Programmiersprache zuwege bringen, selbiges durch den Zwang, innerhalb der Backus-Naur-Notation sich logisch und vollständig ausdrücken zu müssen, das logische Denken endlich beizubringen - oder ersatzeshalber (falls das nicht möglich ist) sie vom Schreiben schlechter Bücher abzuhalten. Das WARUM erkläre ich mir so, daß all diese Leute eben zu ungebildet im Denken sind. Nein, ich meine nicht, daß sie das Zeug, über das sie labern wollen, nicht auswendig gelernt hätten - sondern, daß sie nicht über der Materie stehen, sondern ihr Zeugs nur auswendig gelernt haben und deshalb in ihre Ausführungen keine Systematik hineinbringen können. Kurz gesagt: es ist Unfähigkeit. Und der Einfluß der Ausbildung ist ein negativer: Schon in den Schulen werden die Lehrer von den Eltern der Schüler mit dem Advokaten bedroht, wenn der Schüler zu schlechte Noten für's Abitur heim bringt. Also erlangen viele junge Leute das Abitur, die dafür eigentlich zu doof sind. Das setzt sich dann an den Hochschulen fort, und zum Schluß ist es die Industrie, die auf unfreiwillige Weise die notwendige Selektion erledigen muß. Zum Beispiel, daß Firmen Pleite gehen, wenn deren Entwickler sich zu doof anstellen. Die Alternative ist, daß der jeweilige Chef rectzeitig die Reißleine zieht, den/die Leute rausschmeißt und zusieht, daß er deren Arbeit nach Außerhalb vergibt (was andere Fährnisse bedeutet, aber oftmals der einzige übrig bleibende Weg ist). So sieht das aus. Guck dir die Beiträge in diesem Thread an, da wirst du sehen, wie viele selbsternannte Gurus sich hier großartig über den Rest der Welt erheben wollen, ohne jemals irgend etwas Sinnvolles selbst geleistet zu haben. Genau die sind das, die im realen Leben eine Firma durch ihre Unfähigkeit zugrunde richten würden, wenn man sie ließe. Aber hier im Forum können sie große Töne spucken. Die Welt ist eben voll von Backpfeifen - und es werden immer mehr. zitter_ned_aso schrieb: > Ich denke es ist OK, dass man am Anfang des Buches Begriffe verwendet, > die noch nicht so klar sind. Weil man Fachbücher mehrmals liest. (und > jedesmal entdeckt dabei etwas neues) Eigentlich ist es ganz einfach: Man soll ein Buch oder eine Einführung in ein Thema so schreiben, als ob man es für einen alten Advokaten schriebe. Wohlgemerkt: Der alte Advokat ist kein Dummer, sondern er hat einen rasiermesserscharfen Verstand und eine schnelle Auffassungsgabe. Er kann auch logisch denken und bei hinreichenden Anfangs-Informationen kann er jeden Beweis erfolgreich zuende führen. Er hat auch Bildung und Weltkenntnis. ABER: Er hat keinerlei Kenntnisse über genau DAS Thema, was man gerade zu erklären sich anschickt. Also muß man ihm all das von Anfang an, aber logisch und eindeutig erklären, was man im Folgenden zu benutzen gedenkt. Kurzum, man muß ein Buch logisch aufbauen und Begriffe vor ihrer Verwendung definieren. Genau so, woe man das mit Typen und Variablen in einer Programmiersprache tut. Egon D. schrieb: > Ich HABE schon programmiert. Ich WEISS, wie eine CPU > aufgebaut ist. Und gestützt auf genau dieses Vorwissen > will ich jetzt C lernen! Dann verlasse dich lieber NICHT auf das Gelaber in diesem Forum, sondern suche dir deinen Weg selber. Ich hatte vor Urzeiten am Umarbeiten des Sozobon von K&R auf Ansi mitgearbeitet, selber den Tiny von van Zandt von 8086 auf Z80 mit extrem mäßigem Erfolg die Performance betreffend umgearbeitet und benutze C seit langem für Mikrocontroller - aber nicht, weil ich C so toll fände, sondern nur mangels besserer Alternativen. Lies dich einfach ein anhand diverser Quellen - aber betrachte diese mit Abstand. Sei dir immer klar darüber, daß C keine logische Programmiersprache ist, sondern an fast allen grundlegenden Stellen nach dem Motto gestrickt ist "das ist hier eben so, basta!". Verliere beim Benutzen von C nicht deinen logischen Verstand über die diversen "ist eben so". Und sieh auch die diversen von selbsternannten Gurus verfaßten "Regeln" mit Abstand. Diese gehören nämlich nicht zum eigentlichen Sprachstandard und sind mehrheitlich nicht zuende gedacht. Wahrscheinlich ist es wirklich das Beste, hauptsächlich in Pascal (Delphi, Lazarus) zu programmieren und C an dem zu messen, was man am heutigen Pascal hat. Für einen Eindruck von C++ reicht es aus, sich mal den Stroustrup durchzulesen, um genug davon zu wissen. Und für das Programmieren von µC ist C++ herzlich irrelevant. Man kann es tun, genau so wie man ein Pseudo-Super-Mikro-Linux für einen Atmel AVR schreiben kann, aber es ist eben irrelevant. W.S.
Dr. Sommer schrieb: > Etwas das einem Experten völlig klar ist > kann einem Anfänger große Verständnisprobleme bedeuten; das zu erklären > ist dann schwierig. Die Lern-Schwierigkeiten liegen nicht selten in den Programmiersprachen selbst begründet. Was man schließlich verstanden hat wird in der Anwendung zwar meistens einfach. Die viel entscheidendere Frage ist jedoch, welchen Aufwand der durchschnittliche Programmierinteressierte überhaupt treiben muss um zu diesem Verständnis zu gelangen.
Beitrag #5689389 wurde von einem Moderator gelöscht.
Egon D. schrieb: > Die Art, wie Helmut S. den Stoff gliedert, > gefällt mir schon mal. O tempora o mores! Ich erinnere mich noch gut an Helmut Schellong und die Diskussionen mit und über ihn. Das war damals™ noch im Usenet (die Älteren erinnern sich?) und er galt als Gruppenclown und Lachnummer. Hat er es jetzt ernsthaft zur Authorität und Respektsperson in Sachen C-Programmierung geschafft? Dann kann der Weltuntergang nicht mehr fern sein. Ich pack dann mal die Koffer ...
Egon D. schrieb: > zitter_ned_aso schrieb: > >> Muss man erst mal die Grundlagen von OOP >> beherrschen um "hallo" in der Console auszugeben? > > Wenn man eine objektoriente Sprache verwendet: > Natürlich. Wie denn sonst? > Magst Du noch erläutern, wie weit Objekte für C relevant sind? > Man sollte ja auch die Grundlagen der Zerspanung > beherrschen, wenn ohne Gefahr für Leib und Leben > ein Stück Ding planfräsen will. Wie denn auch > anders? > Besser ist es. Aber was hilft dem Eleven dabei die hehre Schmiedekunst? > >> die C-Tutorials / Bücher setzen da wesentlich weniger >> Vorwissen voraus (behaupte ich mal) > > Mag sein. Die Frage ist, ob das sinnvoll ist. > Die Antwort lautet "ja". > Würdest Du Dich von einem Arzt operieren lassen, der > lediglich "Hirnchirurgie für Dummies" gelesen hat? Würdest Du Dich von jemandem beraten lassen, der auf solchermaßen erbärmlichem Niveau argumentiert?
Dr. Sommer schrieb: > Egon D. schrieb: >> Nein -- wozu? > > Um eine stetige Lernkurve zu erhalten. Viele > Informatiker sind Learning By Doing Menschen und > probieren gerne alles sofort aus. Hmm. Interessant. Vielleicht führt der Gedanke tatsächlich weiter. Ich lerne i.d.R. sehr ausgeprägt zweiphasig. Je komplizierter das Thema ist, desto stärker bin ich am Anfang darauf angewiesen, dass ich mich erstmal grob im Stoff orientieren kann. Das hat wenig mit dem reinen Schreibstil oder mit didaktischer Zuckerbäckerei zu tun, sondern mit einer schwer erklärbaren Fähigkeit des jeweiligen Autors, die innere Struktur des Stoffes deutlich werden zu lassen. In dieser Phase habe ich nur zwei Möglichkeiten: Entweder ich finde eine Quelle, die den Stoff so darstellt, wie ich es brauche, oder ich muss mir ein solches Dokument selbst erarbeiten. Ohne geht es nicht. Den Übergang zu Phase Zwei habe ich nicht in der Hand, das passiert einfach. Irgendwann kommt eine Idee: "Ach, das ist ja interessant, da müsste man doch eigentlich ... tun können", und das probiere ich dann. > Wenn man erst das ganze Buch lesen muss um das > simpelste Hello World schreiben zu können weil > "puts" unter "P" zu finden ist wie im Lexikon, > geht das nicht. Wie schon gesagt: Es stört mich nicht, mit dem Ausprobieren etwas länger zu warten, wenn ich mich im Gegenzug auf mein Wissen verlassen kann. Überdies ist das Schellong-Buch nicht wie ein Lexikon strukturiert, sondern es versucht, die Schwierigkeiten in der Reihenfolge zu behandeln, in der sie typischer- weise auftreten. Es ist völlig stringent, erstmal etwas zur Struktur des Entwicklungssystems zu sagen, dann auf den zulässigen Zeichenvorrat, die Schlüsselworte, die Operatoren, das Typsystem und so weiter zu kommen. Die Sprache wird völlig konsequent aus den elementaren Bestandteilen aufgebaut. Mir ist es -- gerade beim Selbststudium -- über die Maßen wichtig, dass das, was ich mir aneigne, KORREKT ist, also sachlich richtig und vollständig. Das ist bei Lehrmaterial, das eine für mich ERKENNBARE innere Logik hat, wesentlich leichter abzusichern als bei einem, wo das nicht der Fall ist. Ganz abgesehen davon ist es zwar weit verbreitet, aber keineswegs zwingend, dass man das Erlernen einer Programmiersprache von Anfang an mit dem SCHREIBEN von Programmen verbindet. Es gibt ganze Sprachschulen, die darauf aufbauen, dass sich Erwachsene mit einer Sprache leichter durch Hören und Lesen vertraut machen können, und was für lebende Sprachen wahr ist, sollte für Programmiersprachen nicht falsch sein. "Hören" geht zwar bei Quelltexten nicht so gut, aber "Lesen" schon.
Egon D. schrieb: > Ganz abgesehen davon ist es zwar weit verbreitet, > aber keineswegs zwingend, dass man das Erlernen einer > Programmiersprache von Anfang an mit dem SCHREIBEN von > Programmen verbindet. > Es gibt ganze Sprachschulen, die darauf aufbauen, dass > sich Erwachsene mit einer Sprache leichter durch Hören > und Lesen vertraut machen können, und was für lebende > Sprachen wahr ist, sollte für Programmiersprachen nicht > falsch sein. > "Hören" geht zwar bei Quelltexten nicht so gut, aber > "Lesen" schon. Das beschreibt wahrscheinlich recht gut den Grund dafür, dass Max Berlitz in Armut starb und heute völlig vergessen ist.
Axel S. schrieb: > Egon D. schrieb: >> Die Art, wie Helmut S. den Stoff gliedert, gefällt >> mir schon mal. > > O tempora o mores! > > Ich erinnere mich noch gut an Helmut Schellong und die > Diskussionen mit und über ihn. Das war damals™ noch im > Usenet (die Älteren erinnern sich?) und er galt als > Gruppenclown und Lachnummer. Das sagt mehr über Gruppendynamik als über Helmut S. Und wenn ich eines im UseNet gelernt habe, dann ist es, dass das Argument -- und NUR das Argument -- zählt, und nicht, als was eine Person angeblich gilt. > Hat er es jetzt ernsthaft zur Authorität und > Respektsperson in Sachen C-Programmierung geschafft? Häh?! Nochmal ganz langsam zum Mitschreiben: Ich habe -- der Not gehorchend, nicht dem eigenen Triebe -- vor einigen Monaten begonnen, mir ein Repetitorium zur Programmier- sprache C zusammenzuschreiben. Durch den laufenden Thread bin ich darauf gestoßen worden, dass das Buch von Helmut S. EXAKT dieselbe inhaltliche Gliederung verwendet wie mein eigener Text -- und zwar ohne dass ich Helmuts Text gekannt oder irgendwie als Quelle verwendet hätte. Du wirst mir also BITTE verzeihen, wenn meine Auffassung von Autorität und Gruppenclowns mit der Deinen nicht ganz deckungsgleich ist. Und nur vorsorglich: Ich kann sehr gut damit leben, jetzt auch in Deiner Gruppenclown-Schublade zu stecken. > Dann kann der Weltuntergang nicht mehr fern sein. Ich > pack dann mal die Koffer ... Nun ja. Ich glaube, es ist Max Planck gewesen, der gesagt hat, der Fortschritt in der Wissenschaft vollziehe sich nicht so, dass ihre Gegner nach und nach überzeugt würden, sondern vielmehr würden die Gegner einfach aussterben, und die Jugend würde von Vornherein mit der Wahrheit vertraut gemacht.
Anton M. schrieb: > Die viel entscheidendere Frage ist > jedoch, welchen Aufwand der durchschnittliche Programmierinteressierte > überhaupt treiben muss um zu diesem Verständnis zu gelangen. Ich weiß noch, als das mit Basic losging, gingen ein paar Wochen und Monate ins Land bis die "Abstrakta" einigermaßen saßen. Viel war es ja nicht. Die Hürde waren nur noch komplexere Programme und coole Herausforderungen - sprich - das Motivationsszenario und Glück im Ausbildungsweg. Auch noch eine Rolle spielt die Lerngeschwindigkeit. Man muss z.B. das Tempo von Uni-Onlinekursen nicht mitgehen. Wenn man aber am Ball bleibt, kommt man schnell vorwärts. Aber je schneller gelernt, desto schneller vergessen, d.h. auch darauf muss man achten, dass das Gelernte nicht gleich wieder abhaut. Im Studium habe ich noch gelernt, dass besonders schwierige, abstrakte Bücher für mich leichter verständlich werden, wenn ich auf Fernsehen und andere Medien verzichte. Das plakative, Aufmerksamkeit heischende Schlagzeilenszenario der Medien stört die innere Strukturfindung sehr. Das dauert eine Weile bis man das merkt, so 2-3 Wochen. Wenn man am Ball bleibt, kann man für die erste Einstiegshürde 8 Wochen rechnen. Aber auch nur, wenn der Motivationsrahmen einigermaßen stimmt. Ohne Motivation kein Lernen. (das ist für Schlaganfallpatienten ein großes Problem, weil das Nervensystem (vermutlich)(auch) aus Schutzgründen Funktionen blockiert. D.h. die Krankenkassen lassen diese Patienten in "Selbsthilfegruppen" im Stich.) Das ist aber nur eine Nebenbemerkung. Ohne Motivation kein Lernen!! Programmieren ist auch immer Handwerk und als solches gilt das gleiche wie bei Musikinstrumenten: Üben, üben, üben. Die praktische Übung kann einem kein Buch abnehmen. Den Aha-Effekt beim Problemlösen kann einem kein Buch abnehmen. Früher gab es aber richtig gute Rätselbücher in Läden oder in Stadtbüchereien, die halfen weiterzukommen, heute dagegen.. (Bücherverbrennung 2.0)
Au weia, man darf nicht schlafen gehen wenn man hier schreibt. Egon: Du hast einen sehr unüblichen Lerntyp. Daher würde ich deine Vorgehensweise nicht pauschal jedem Anfänger vorschlagen. Ich könnte so nicht lernen. Und die allerwenigsten schreiben sich erstmal ein Repetitorium. Objekte sind übrigens auch sehr wohl für C relevant. Der Linux Kernel z.B. ist in C größtenteils objektorientiert programmiert. Und C++ ist natürlich auch für uC relevant - wie schon wiederholt bewiesen wurde, kann man das da sehr gut benutzen. Tatsächlich sehe ich überhaupt keinen Grund C zu lernen. Warum nicht gleich C++? Sollte man doch irgendwann mal C brauchen, lässt man all das weg was C nicht hat (und fragt sich warum man sich mit so etwas eingeschränkten abgeben muss) und fügt die 3 Details hinzu die C-exklusiv sind. Die Frage ist jetzt aber - wie würde Egon C++ lernen? C++ ist in seiner Gesamtheit extrem komplex. Man braucht mindestens 5-10 Jahre um das alles zu verstehen. Wenn man das A-Z durcharbeitet, hat man nach 5 Jahren dann sein erstes Hello World und hoffentlich nicht vergessen, was man ganz am Anfang gelernt hat! Natürlich sind all diese Details für die praktische Anwendung völlig irrelevant - man könnte innerhalb kürzerer Zeit die Dinge lernen, die man für "normale" Programme braucht. Das ginge aber nicht mit einem Schellong-artigen Buch. Hast du unter den Hunderten Büchern wirklich nur K&R und Schellong gefunden? Da gab es kein besseres, welches sich an Programmierer richtet aber nicht erstmal ein Repetitorium erfordert?
Dr. Sommer schrieb: > Objekte sind übrigens auch sehr wohl für C relevant. Der Linux Kernel > z.B. ist in C größtenteils objektorientiert programmiert. Prächtig. Noch prächtiger finde ich allerdings, dass der Anfänger in C nicht gezwungen ist, gleich sein erstes HelloWorld mit Objekten zu überfrachten. > Und C++ ist > natürlich auch für uC relevant - wie schon wiederholt bewiesen wurde, > kann man das da sehr gut benutzen. Nun, es wutde ausdrücklich nach C gefragt. Als Zusatzinformation mag Deine Bemerkung angehen. Tatsächlich sehe ich überhaupt keinen > Grund C zu lernen. Das ist dann vermutlich allgemeinverbindlich ... > Warum nicht gleich C++? Sollte man doch irgendwann > mal C brauchen, lässt man all das weg was C nicht hat (und fragt sich > warum man sich mit so etwas eingeschränkten abgeben muss) und fügt die 3 > Details hinzu die C-exklusiv sind. > Wenn Du in der Kneipe ein Schankbier bestellst und der Kellner schenkt ein Vollbier aus, weil das ja sowieso besser ist - bist Du dann zufrieden? > Die Frage ist jetzt aber - wie würde Egon C++ lernen? Warum? Erst einmal ist Philip dran! > C++ ist in seiner > Gesamtheit extrem komplex. Man braucht mindestens 5-10 Jahre um das > alles zu verstehen. Wenn man das A-Z durcharbeitet, hat man nach 5 > Jahren dann sein erstes Hello World und hoffentlich nicht vergessen, was > man ganz am Anfang gelernt hat! Natürlich sind all diese Details für die > praktische Anwendung völlig irrelevant - man könnte innerhalb kürzerer > Zeit die Dinge lernen, die man für "normale" Programme braucht. Das > ginge aber nicht mit einem Schellong-artigen Buch. Das berühmte C++ Kompendium? > Hast du unter den Hunderten Büchern wirklich nur K&R und Schellong > gefunden? Da gab es kein besseres, welches sich an Programmierer richtet > aber nicht erstmal ein Repetitorium erfordert? Für C++ oder für C?
Percy N. schrieb: > Prächtig. Noch prächtiger finde ich allerdings, dass der Anfänger in C > nicht gezwungen ist, gleich sein erstes HelloWorld mit Objekten zu > überfrachten. Da ist gar nix überfrachtet. OOP ist eine sehr intuitive Auffassung der Welt. Wer direkt damit anfängt kann sich damit super orientieren. Percy N. schrieb: > Nun, es wutde ausdrücklich nach C gefragt. W.S. hat aber Unfug über C++ geschrieben. Dem wollte ich entgegenwirken. Percy N. schrieb: > Wenn Du in der Kneipe ein Schankbier bestellst Wenn ich Anfänger bin und die Vorteile nicht beurteilen kann, ist das doch sehr nett von ihm. Percy N. schrieb: > Das berühmte C++ Kompendium? Hä? Es gibt gute Bücher über C++. z.B. die von Stroustrup. Die gehen auch nicht A-Z vor. "The C++ programming language" setzt z.B. Kenntnisse i n einer Sprache voraus, fängt also nicht bei Adam und Eva an, aber arbeitet sich von einfachen C++ Programmen an vor. Man muss es also nicht komplett durchlesen um damit arbeiten zu können - das würde auch ganz schön lange dauern, und am Ende hätte man vergessen was am Anfang stand. Percy N. schrieb: > Für C++ oder für C? Bezog sich auf C. Gilt aber auch für andere Sprachen.
Dr. Sommer schrieb: > Da ist gar nix überfrachtet. OOP ist eine sehr intuitive Auffassung der > Welt. Wer direkt damit anfängt kann sich damit super orientieren. > Gleichwohl ist es komplexer als ohne. > Percy N. schrieb: >> Nun, es wutde ausdrücklich nach C gefragt. > > W.S. hat aber Unfug über C++ geschrieben. Dem wollte ich entgegenwirken. > Das scheint eine größere Aufgabe zu werden ;-)) > Percy N. schrieb: >> Wenn Du in der Kneipe ein Schankbier bestellst > > Wenn ich Anfänger bin und die Vorteile nicht beurteilen kann, ist das > doch sehr nett von ihm. > Bitte sieh mir nach, dass ich diese Auffassung nicht teile. Wenn ich etwas bestelle, dann möchte ich genau das geliefert bekommen. Wenn ein Verkäufer mir ohne Nachfrage etwas anderes als das bestellte präsentiert, falte ich ihn zusammen und verlasse den Laden. Wenn er mir zunächst entgegen hält, Metabo sei aber viel besser als Haribo, dann gibt es auch Ärger. Falls er fragt, ob er auch etwas anderes andienen darf, ist alkes in bester Ordnung und der Bursche hat ein Lob verdient. Dir steht es selbstverständlich frei, durch das Verschulden eines eigenmächtigen Kellners Deinen Führerschein einzubüßen. > Percy N. schrieb: >> Das berühmte C++ Kompendium? > > Hä? Es gibt gute Bücher über C++. z.B. die von Stroustrup. ... Vergiss es ... Btw: Wieso begründet die Möglichkeit, in C oo zu programmieren, wenn man es denn unbedingt will, die Relevanz von Objekten für das Erlernen von C? Wenn Du Fieber hast, legst Du Dich vermutlich ins Bett und schluckst ASS. Mit einem übelst verdorben Magen wirst Du vermutlich auch das Bett hüten. Also schluckst Du auch da ASS, auf nüchternen Magen? Gute Besserung!
:
Bearbeitet durch User
Percy N. schrieb: > Gleichwohl ist es komplexer als ohne. Da wär ich mir nicht so sicher. OOP-Sprachen (Java, C++, Python, ...) haben z.B. auch einfachere String-Verarbeitung. Das hilft einem Anfänger auch sehr. Ich würde einem Anfänger lieber OOP erklären als die Bedeutung von "char* argv []". Percy N. schrieb: > Bitte sieh mir nach, dass ich diese Auffassung nicht teile. Man kann ja wohl zumindest vorschlagen, eine Alternative in Betracht zu ziehen. Percy N. schrieb: > falte ich ihn zusammen und verlasse den Laden. Weil du also aufgrund von (vermutlich) Unwissen und mangelnder Überlegung (so sieht es beim TO aus) etwas bestimmtes haben willst, bestehst du felsenfest darauf das zu bekommen und stellst dich absolut beratungsresistent? Der Albtraum eines jeden Service-Mitarbeiters. Percy N. schrieb: > Btw: Wieso begründet die Möglichkeit, in C oo zu programmieren, wenn man > es denn unbedingt will, die Relevanz von Objekten für das Erlernen von > C? Weil OOP auch die meisten C-Programme besser strukturiert. Da kann man sich gut dran halten.
Habe selber leider viel zu spät den K&R "entdeckt" weil ich dachte "der ist doch sooo alt". Ist aber meiner Meinung nach immer noch das Buch der Wahl, wenn man schon etwas Ahnung vom Programmieren hat (das ist leider Vorraussetzung) und wenn man eine kurze und knappe Einführung sucht, die trotzdem vollständig ist. Wem der K&R zu kurz greift, dem empfehle ich "C Primer Plus" von Stephen Prata. Ein richtiger Schinken, voller Beispiele und Erklärungen, sowie auch Übungen. Es bleiben eigentlich keine Fragen offen. Wenn man nur ein einziges Buch über die Sprache C besitzen dürfte, dann würde ich definitiv dieses empfehlen.
Walter T. schrieb: > Offensichtlich ist es deutlich wichtiger, den blöden Anfängern klar zu > machen, warum dieses oder jenes Buch schlecht ist, als zu erklären, was > an bestimmten Büchern gut ist. Dann mache ich das mal aus dem Kopf für den ANSI-K&R: Es ist klar strukturiert, vom Einfachen zum Komplexen. Ausnahme, das klassische "Hello World" zum Einstieg, das dann systematisch abgehandelt wird. Es setzt keine spezielle IDE voraus. Überhaupt, es konzentriert sich auf die Sprache, nicht auf das mechanische Antrainieren von Klickpfaden durch Tools wie IDEs, Editoren für Codemonkeys die klicken ohne Nachzudenken. So verschwendet es nicht die Zeit des Lesers damit ihm als Computerbenutzern zu erklären wie er seinen Computer einzuschalten hat oder wie er ein Programm installieren. Allgemein, der Leser wird nicht für komplett verblödet gehalten, man gesteht ihm zu das er selbstständig Denken kann, sich alleine Anziehen kann und seine Hose nicht mit der Kneifzange zu macht. Der Leser wird auch nicht verarscht mit irgendwelche Jubel-Lob wenn er irgendwas erfolgreich gemacht hat, als ob man ein Hund wäre "Fein gemacht! Ganz toll wie du das Stöckchen geholt hast". Dem Leser wird keine tolle Karriere, keine goldene Zukunft mit viel Koks und leichten Mädchen in Silicon Valley versprochen, nur weil er C lernt. Auch gibt es keinen Bullshit wie "Teach Yourself C in 24 Hours" und keinen Trash-Talk über andere Programmiersprachen. Nicht zuletzt weil so ein Blödsinn fehlt ist es kompakt. Es ist trotz der Kompaktheit unterhaltend und nicht langweilig. Es ist nahezu zeitlos, trotz des Alters. Das wenige Zeitkolorit stört nicht und trägt zur Unterhaltung bei. Als Beispiele werden fast ausschließlich komplette (lauffähige) Mini-Programme oder wenigstens Funktionen, statt zusammenhanglose Codefragmente, verwendet. Der Leser wird von Anfang an animiert selber Mini-Programme zu schreiben oder wenigstens die gezeigten Programme auszuprobieren. Neben dem Lehrbuch-Teil ist eine Sprachreferenz enthalten. Ebenso gibt es einen Blick in die wichtigsten Funktionen aus der Standardbibliothek. Nicht nur von außen, sondern auch was intern abläuft.
Dr. Sommer schrieb: > Percy N. schrieb: >> Bitte sieh mir nach, dass ich diese Auffassung nicht teile. > > Man kann ja wohl zumindest vorschlagen, eine Alternative in Betracht > zu ziehen. > Vorschlagen ja. Oktroyieren nein. > Percy N. schrieb: >> falte ich ihn zusammen und verlasse den Laden. > > Weil du also aufgrund von (vermutlich) Unwissen und mangelnder > Überlegung (so sieht es beim TO aus) etwas bestimmtes haben willst, > bestehst du felsenfest darauf das zu bekommen und stellst dich absolut > beratungsresistent? Der Albtraum eines jeden Service-Mitarbeiters. > Wenn Du nicht des Willens oder nicht in der Lage bist, mehrere Sätze im Zusammenhang zu verstehen, brauchst Du noch lange nicht ausfallend zu werden. Das erwähnte Lob kam allerdings ohnehin nicht mehr in Frage. > Percy N. schrieb: >> Btw: Wieso begründet die Möglichkeit, in C oo zu programmieren, wenn man >> es denn unbedingt will, die Relevanz von Objekten für das Erlernen von >> C? > > Weil OOP auch die meisten C-Programme besser strukturiert. Da kann man > sich gut dran halten. Das las sich oben etwas anders.
Wenn du die kurze Begründung schon als "Oktroyieren" siehst... Da ist wohl jemand auf dem C++-Auge überempfindlich.
Dr. Sommer schrieb: > Wenn du die kurze Begründung schon als "Oktroyieren" siehst... Da ist > wohl jemand auf dem C++-Auge überempfindlich. Aber nicht doch. Dein Disput mit Egon war so kurz nicht. Aber vielleicht schert nicht jeden sein Geschwätz von gestern.
Dr. Sommer schrieb: > Rufus Τ. F. schrieb: >> Ich hab' das Gefühl, daß Du mit der "Lernbetty" von W.S. glücklich >> werden könntest. > > Bei der krieg ich Ausschlag wenn ich den Programmierstil sehe. Die kann > man als Negativbeispiel nutzen, wie man es nicht machen sollte... Hier mal ein "Juwel" aus der Lernbetty:
1 | if (!Focussed) |
2 | { *P = 0; |
3 | Tem = self->Members; |
4 | while (Tem) |
5 | { if (Tem->Flags & canFocus) |
6 | { *P = Tem; |
7 | goto der_erstbeste; |
8 | }
|
9 | else Tem = Tem->danach; |
10 | }
|
11 | |
12 | isEditing = 0; /* ohne Fokussierbaren gibt es nix zu editieren! */ |
13 | return; /* und ohne Fokussierbaren gibt es auch sonst nichts zu tun! */ |
14 | |
15 | der_erstbeste:
|
16 | Focussed = Tem; |
17 | }
|
Dieser ständige Mischmasch aus deutsch und englisch kenne ich sonst nur von Anfängern, aber das Gehacke mit dem goto ist dann schon echt grob. Und das sage ich als jemand, der goto zur Fehlerbehandlung (besonders der gestackten) durchaus befürwortet. Auch "hübsch":
1 | loop1:
|
2 | CgPixel_at(x,y,mode); |
3 | if (x == B.X) return; |
4 | x = x + xInc; |
5 | D = D + M; |
6 | if (D > HX) |
7 | { y = y + yInc; |
8 | D = D - c; |
9 | }
|
10 | goto loop1; |
Da hat offensichtlich jemand ein Problem, sich mal vernünftige Schleifenbedingungen zu überlegen. So ein Murks ist allenfalls gut, damit man testet, ob das Codereview was taugt und sowas durchfallen läßt. Und dann noch das ganze Gewürge mit byte, word und dword, was so aussieht, als wenn ein Pascal-Programmierer sich seine Pascal-Typen in C zusammendefiniert hätte. Auch nicht zur Nachahmung empfohlen.
> Dieser ständige Mischmasch aus deutsch und englisch kenne ich
Dieser ständige Mischmasch aus deutsch und englisch - sowas kenne ich
Um noch ein Buch in die Runde zu werfen: Die deutschsprachige Dokumentation zu Turbo C 2.0 von Borland. Die war keine Übersetzung der englischen Dokumentation, sondern wurde von Arne Schäpers mehr oder weniger komplett neu geschrieben. Das zusammen mit dem K&R (in zweiter Ausgabe) ist für den Anfang ausreichend gutes Werkzeug. Problem ist die Verfügbarkeit, ich hatte mein Exemplar vor jetzt 30 Jahren gekauft ...
Egon D. schrieb: > Axel S. schrieb: > >> Ich erinnere mich noch gut an Helmut Schellong und die >> Diskussionen mit und über ihn. Das war damals™ noch im >> Usenet (die Älteren erinnern sich?) und er galt als >> Gruppenclown und Lachnummer. > > Das sagt mehr über Gruppendynamik als über Helmut S. Nein. > Und wenn ich eines im UseNet gelernt habe, dann ist es, > dass das Argument -- und NUR das Argument -- zählt Ja. Eben. Die Beurteilung von H. Schellong haben wir damals ja nicht aus dem Kaffeesatz gelesen, sondern die ergab sich aus seinem Auftreten. Aus dem, was er gesagt und vor allem was er gefragt hat. Damals war er in der Situation, in der unser TE heute ist - er wollte eine Programmiersprache lernen und hat sich an ein Forum gewandt, um Hilfe zu bekommen. Soweit alles ok. Allerdings hat er sich dann (milde ausgedrückt) sehr ungeschickt angestellt. Die einfachsten Dinge mußten ihm zigmal erklärt werden. Das hat viele Leute die Decke hochgetrieben und ihm seinen Ruf eingebracht. Ich habe Details vergessen. Aber vielleicht findet man es noch in einem Archiv. War eine der de.comp.lang Gruppen. Mußmaßlich de.comp.lang.c. >> Hat er es jetzt ernsthaft zur Authorität und >> Respektsperson in Sachen C-Programmierung geschafft? > > Häh?! Ja. Stell dir einfach vor, der dümmste Schüler aus deiner Schulklasse (zweimal sitzen geblieben) würde für den Physik-Nobelpreis nominiert. Das wäre ungefähr der gleiche Grad an Überraschung. Aber wer weiß, vielleicht ist er ja ein Spätstarter oder war damals noch sehr jung (im Usenet weiß man nicht, wie alt ein Teilnehmer ist, nach einem gängigen Sprichwort könnte es sogar ein Hund sein). Ich kenne sein Buch nicht und die Chancen, daß ich es mal lese, sind gering. Ich kann C mittlerweile und habe wichtigeres zu Lesen.
Nop schrieb: > Hier mal ein "Juwel" aus der Lernbetty: Das steht da ernsthaft? Und der Autor dieses Codes will uns in diesem Thread erklären das wir unfähig zu Denken sind? Ich bin dann mal raus. "Muss los, Nasenbluten."
Am Besten gefällt mir das:
1 | #ifndef _STDTYPES_INCLUDED
|
2 | #define _STDTYPES_INCLUDED
|
3 | |
4 | |
5 | /************** Daten-Typen ********************/
|
6 | |
7 | #define integer short int
|
8 | #define word unsigned short int
|
9 | #define byte unsigned char
|
10 | #define dword unsigned long
|
11 | #define qword unsigned long long
|
12 | #define int64 long long
|
13 | #define bool unsigned char
|
14 | |
15 | #define TRUE 1
|
16 | #define true 1
|
17 | #define FALSE 0
|
18 | #define false 0
|
19 | |
20 | /* schlecht merkbare Kringels */
|
21 | #define MOD %
|
22 | #define XOR ^
|
23 | #define NOT ~
|
24 | #define AND &
|
25 | #define OR |
|
26 | |
27 | |
28 | |
29 | #define POINT struct TPoint
|
30 | struct TPoint |
31 | { integer X, Y; }; |
32 | |
33 | #define RECT struct TRect
|
34 | struct TRect |
35 | { integer left, |
36 | top, |
37 | right, |
38 | bottom; |
39 | };
|
40 | |
41 | |
42 | /* --- */
|
43 | #endif
|
Es fängt schon damit an dass die Include Guards verbotene Bezeichner sind (fangen mit Unterstrich an). Dann werden Makros statt typedef für Typaliase verwendet. Dann werden ziemlich skurrile Typnamen verwendet (warum nicht stdint.h?). Dann wird "true" definiert obwohl man einfach stdbool.h nehmen könnte. Dann werden Makros für Operation definiert obwohl man einfach "and", "or" usw. nutzen könnte. Seltsame Einrückungsstile ignorier ich mittlerweile sowieso. In anderen Dateien immer "extern" an Funktionsdeklarationen, obwohl es absolut keine Wirkung hat. Aber immer dran denken - W.S. ist der einzige Intellektuelle hier und so "Regeln" wie die sinnvolle Verwendung von "typedef" oder "and" schränken sein Genie unnötig ein.
Beitrag #5690149 wurde vom Autor gelöscht.
Marten Morten schrieb: > Das steht da ernsthaft? Jepp, siehe Beitrag "Re: Die Lernbetty: Die SwissBetty von Pollin als ARM-Evalboard" . Hier noch ein Leckerli:
1 | Schleife:
|
2 | if (c=='.') { c= *Pt++; dp_seen=1; } |
3 | if (c<'0') goto Schlend; |
4 | if (c>'9') goto Schlend; |
5 | i = c - '0'; |
6 | R = R * 10.0 + i; |
7 | if (dp_seen) T = T * 10.0; |
8 | c = *Pt++; |
9 | goto Schleife; |
10 | |
11 | Schlend: |
So ein Murks - sieht doch jeder, daß es Schlaaand hätte heißen müssen. > Und der Autor dieses Codes will uns in diesem > Thread erklären das wir unfähig zu Denken sind? Frag Dich lieber, was herausgekommen, wenn ihn auch noch jemand auf die Existenz von setjmp/longjmp hingewiesen hätte. Damit kann man jede unnütze goto-Orgie wie einen Kindergeburtstag aussehen lassen. Dr. Sommer schrieb: > > /* schlecht merkbare Kringels */ LOL - Bester!
Dr. Sommer schrieb: > Egon: Du hast einen sehr unüblichen Lerntyp. Ja, das ist sicherlich richtig. > Daher würde ich deine Vorgehensweise nicht pauschal > jedem Anfänger vorschlagen. Um Himmels Willen -- nein. Natürlich nicht. Das Allerwichtigste ist, dass jeder für sich selbst erkennt, welcher Lerntyp er ist. Einer der vernünftigsten Ratschläge hier im Thread war, einfach in die Bibliothek zu gehen und verschiedene Bücher durchzuprobieren. Mit welchen Stil man klarkommt, ist eine sehr individuelle Sache, die sich schlecht erklären oder von einer Person auf die andere übertragen lässt. Ich bin in diese Diskussion auch nur eingestiegen, weil das Schellong-Buch in Grund und Boden verrissen wurde, was ich in dieser Form nicht angemessen fand. > Objekte sind übrigens auch sehr wohl für C relevant. > [...] Ist das noch an mich adressiert? Ich habe bisher absichtlich noch keine Stellung zu C++ genommen; ich wollte den Thread nicht noch weiter kapern. > Die Frage ist jetzt aber - wie würde Egon C++ lernen? Das ist eine sehr gute Frage. Tatsächlich habe ich kurz mit dem Gedanken gespielt, gleich C++ statt erst C zu lernen (auch, weil das vielfach so empfohlen wurde), ihn dann aber bald verworfen: Ich hatte einfach das Gefühl, dass dieser Brocken zu groß für mich ist. Der Spatz in der Hand ist mir lieber als die Taube auf dem Dach. Das ist aber ein weites Feld, was auch damit zusammenhängt, dass das Konzept der OOP zwar gut ist, die Erklärungen aber IMHO überwiegend bescheuert sind. > Hast du unter den Hunderten Büchern wirklich nur K&R > und Schellong gefunden? Nee. Auf den Schellong bin ich ja erst in diesem Thread aufmerksam gemacht worden. (Vielleicht besorge ich mir tatsächlich mal die gedruckte Ausgabe.) Der K&R war zufällig ohnehin schon da -- außerdem wurde er als DER Klassiker vielfach empfohlen. Ich finde ihn auch interessant -- aber ich lese ihn als historisches Dokument. Er repräsentiert den Stand von vor 30 Jahren. Wenn man irgend ein Detail über die Sprache verbindlich wissen will, muss man sowieso in den Standard gucken... > Da gab es kein besseres, welches sich an Programmierer > richtet aber nicht erstmal ein Repetitorium erfordert? Ach, nee,... ich glaube, das kommt irgendwie falsch 'rüber. Die Mühe, mich mit dem Stoff selbst auseinanderzusetzen, nimmt mir letztlich niemand ab. Mein Problem ist ja weniger, dass ich unsicher wäre, wie ein bestimmtes Sprachelement wirkt -- mein Problem ist, dass ich mich auf Schritt und Tritt frage: "Warum? WARUM? WARUM NUR ist das dermaßen gehirntot festgelegt worden?" Diese Fragen -- und die zugehörigen Antworten, so ich denn welche finde -- tippe ich in den Computer. Das ist schon alles. Das ist im Moment mein Weg, mich mit dem Lernstoff vertraut zu machen. Andere schreiben Dutzende seitenlange Programme, ich schreibe nur ab und an mal einen Dreizeiler und arbeite ansonsten an meinem Repetitorium. Sicher könnte mir ein gutes Buch einen Teil der Mühe abnehmen, aber bisher war der Leidensdruck noch nicht groß genug, um ernsthaft auf die Suche zu gehen. Außerdem gibt es da noch die Diskussionen auf µC.net als Informationsquelle... :)
Dr. Sommer schrieb: > Dann werden ziemlich skurrile Typnamen verwendet Skurril nur für den, der Pascal skurril findet. > Dann wird "true" definiert obwohl man einfach > stdbool.h nehmen könnte. Bei ANSI-C? > Dann werden Makros für Operation definiert obwohl > man einfach "and", "or" usw. nutzen könnte. Bei ANSI-C? > Seltsame Einrückungsstile ignorier ich mittlerweile > sowieso. Soviel Kompromissbereitschaft muss auch sein. Ich bin eigentlich auch nicht bereit, meinen Klammerungs- und Einrückungsstil nur deshalb zu ändern, weil der Rest der Welt noch nie von Tcl gehört hat...
Egon D. schrieb: > "Warum? WARUM? > WARUM NUR ist das dermaßen gehirntot festgelegt worden?" C ist halt so :-) Deswegen nutzt man das auch nur wenn es unbedingt sein muss. Leider hat es noch sehr viele Fans die das genau so gut finden (Torvalds & Konsorten). Ist wohl so eine Art Stockholmsyndrom. Egon D. schrieb: > Skurril nur für den, der Pascal skurril findet. Zumindest mal sehr unüblich für C und C++. Die Namensgebung ist mindestens mal inkonsistent. Egon D. schrieb: > Bei ANSI-C? Warum muss man unbedingt den C-Standard von 1989 benutzen? Seitdem sind viel Zeit und neue Standards ins Land gegangen. Die Prozessor (LPC2220) ist von 2004, man hätte also von Anfang an mal C99 nehmen können.
Axel S. schrieb: > Egon D. schrieb: >> Axel S. schrieb: >> >>> Ich erinnere mich noch gut an Helmut Schellong und die >>> Diskussionen mit und über ihn. Das war damals™ noch im >>> Usenet (die Älteren erinnern sich?) und er galt als >>> Gruppenclown und Lachnummer. >> >> Das sagt mehr über Gruppendynamik als über Helmut S. > > Nein. Du gestattest, dass ich bei meiner abweichenden Meinung bleibe. >> Und wenn ich eines im UseNet gelernt habe, dann ist es, >> dass das Argument -- und NUR das Argument -- zählt > > Ja. Eben. > > Die Beurteilung von H. Schellong haben wir damals ja nicht > aus dem Kaffeesatz gelesen, sondern die ergab sich aus > seinem Auftreten. Ja -- aber nicht nur. Sie ergab sich auch aus eurem Urteil über sein Auftreten, aus eurer (gemeinsamen) Reaktion und seiner Gegenreaktion. Genau das ist das, was man Gruppendynamik nennt. Du musst mir nix vom Pferd erzählen; ich war lange genug im UseNet dabei (wenn auch nicht in *.lang.c), und ich bin auch hier schon lange genug dabei. Ich weiss auch, wie aggressiv Diskussionen zwischen Leuten hochkochen können, die einzeln ganz normal und friedlich sind. Erzähl' mir nix. Dass jemand mit der Mehrheit mitgröhlt, ist kein Beleg dafür, dass er Recht hat, und dass er als Außenseiter ausgegrenzt wird, kein Beweis, dass er Unrecht hat. (Umgekehrt natürlich auch nicht.) > Damals war er in der Situation, in der unser TE heute > ist - er wollte eine Programmiersprache lernen und hat > sich an ein Forum gewandt, um Hilfe zu bekommen. Soweit > alles ok. Allerdings hat er sich dann (milde ausgedrückt) > sehr ungeschickt angestellt. Die einfachsten Dinge mußten > ihm zigmal erklärt werden. Das hat viele Leute die Decke > hochgetrieben und ihm seinen Ruf eingebracht. Das glaube ich Dir alles aufs Wort -- aber ich ziehe wohl lediglich eine andere Schlussfolgerung als Du. Ich lese aus Deiner Schilderung nur heraus, dass er ein Außenseiter war und hartnäckig einen (=seinen) Minderheitenstandpunkt vertreten hat. Ob dieser "richtig" oder "falsch" ist, ist bis hierhin noch völlig offen. >>> Hat er es jetzt ernsthaft zur Authorität und >>> Respektsperson in Sachen C-Programmierung geschafft? >> >> Häh?! > > Ja. Stell dir einfach vor, der dümmste Schüler aus > deiner Schulklasse (zweimal sitzen geblieben) würde > für den Physik-Nobelpreis nominiert. Naja... nimm mir's nicht übel, aber ich kann nix für Deine Arroganz, die Dich offenbar verleitet hat, Außenseitertum mit Dummheit zu verwechseln. (Und ich will mich gar nicht über Dich erheben -- ich bin auch nicht frei davon; mir ist das auch passiert.) > Aber wer weiß, vielleicht ist er ja ein Spätstarter > oder war damals noch sehr jung (im Usenet weiß man > nicht, wie alt ein Teilnehmer ist, nach einem gängigen > Sprichwort könnte es sogar ein Hund sein). Ich kenne > sein Buch nicht und die Chancen, daß ich es mal lese, > sind gering. Ich kann C mittlerweile und habe > wichtigeres zu Lesen. Nun ja... es mag ja eine der Todsünden sein, aber es erfüllt mich mit tiefer, hämischer Freude, dass es offensichtlich jemand, der im UseNet in der C-Gruppe niedergebrüllt wurde, geschafft hat, ein C-Lehrbuch bei Springer (!) zu veröffentlichen. Ich werde mir sein Buch also sehr gründlich ansehen :)
Philipp L. schrieb: > Jetzt habe ich wieder ein paar Ideen, möchte aber gern mit C beginnen. Hi, ich habe jetzt nicht alles gelesen :-) aber ich mache es folgendermassen: suche dir ein Tutorial (vorzugsweise als PDF-Datei) und suche dir ein Forum dazu. Arbeite das Tutorial durch und stelle Fragen im Forum, wenn du Probleme hast. Dabei wirst du möglicherweise auf zwei Dinge stossen: es wird dir vielleicht gesagt, dass dein Tutorial "Mist" ist! Sofern diese Aussage für dich nachvollziehbar begründet ist, kannst du das vorgeschlagene Tutorial probieren. Zweitens wirst du vielleicht feststellen, dass dir im Forum nicht wirklich geholfen wird...aus verschiedensten Gründen...dann suchst du dir ein neues Forum! Die eigene Lernkurve ist dabei "fast" opimal. Besonders die Formulierung der Fragen fürs Forum ist eine exellente Übung, um ein Problem wirklich zu verstehen. Das klappt nach einigen Versuchen immer besser! Gutes Gelingen, Rainer
Egon D. schrieb: > Naja... nimm mir's nicht übel, aber ich kann nix für > Deine Arroganz, die Dich offenbar verleitet hat, > Außenseitertum mit Dummheit zu verwechseln. (Und ich will > mich gar nicht über Dich erheben -- ich bin auch nicht > frei davon; mir ist das auch passiert.) Such doch einfach mal hier im Forum nach Beiträgen von diesem Axel S. Immer der gleiche Stil, immer die gleiche Arroganz Anderen gegenüber.
Dubslav von Stechlin schrieb: > Egon D. schrieb: > >> Naja... nimm mir's nicht übel, aber ich kann nix für >> Deine Arroganz, die Dich offenbar verleitet hat, >> Außenseitertum mit Dummheit zu verwechseln. (Und ich will >> mich gar nicht über Dich erheben -- ich bin auch nicht >> frei davon; mir ist das auch passiert.) > > Such doch einfach mal hier im Forum nach Beiträgen von > diesem Axel S. Immer der gleiche Stil, immer die gleiche > Arroganz Anderen gegenüber. Nicht immer nur den Teil lesen, der einem gefällt. Da steht noch ein Nachsatz in Klammern. "Wer ohne Sünde ist, der werfe den ersten Stein."
Nop schrieb: > Hier mal ein "Juwel" aus der Lernbetty: > ... > Auch "hübsch": > ... Dr. Sommer schrieb: > Am Besten gefällt mir das: > ... Nop schrieb: > noch ein Leckerli: > ... Jetzt verstehe ich endlich, warum W.S. ein so engagierter C-Gegner ist. Wann man in C tatsächlich nur in diesem Stil programmieren könnte, würde ich C ebenfalls entschieden ablehnen und auf Pascal umschwenken ;-) Zurück zum Thema: Hat sich eigentlich schon einmal jemand das Buch "C Programming: A Modern Approach" von K. N. King angeschaut? Es deckt C99 ab, wird in englischsprachigen Foren oft als umfassendes Werk für C-Einsteiger vorgeschlagen und wird auch auf Amazon recht gut bewertet. Es ist mit 66,23€ nicht ganz billig und hat mit 832 Seiten eher den Umfang eines C++-Buchs, was für meinen Geschmack viel zu viel ist¹. Trotzdem scheint das Buch von King weniger kritisiert zu werden als andere C99- oder C11-Bücher. Vielleicht hat es ja das Zeug dazu, sich sich zum Standardwerk für C99 zu entwickeln. —————————————— ¹) Zum Vergleich: K&R (2nd edition) benötigt für C89 nur 272 Seiten, hochgerechnet auf C99 oder C11 wären das maximal ca. 320 Seiten.
Ich finde dieses hier noch recht interessant. Habe bisher leider noch nicht die Zeit gefunden darin länger als ein paar Stunden zu lesen. http://icube-icps.unistra.fr/index.php/File:ModernC.pdf Und für etwas später vielleicht noch ein paar "Patterns in C". https://stackoverflow.com/a/9125140/6621062
Rufus Τ. F. schrieb: > Um noch ein Buch in die Runde zu werfen: [...] > > Das zusammen mit dem K&R (in zweiter Ausgabe) ist für den Anfang > ausreichend gutes Werkzeug. Problem ist die Verfügbarkeit, ich hatte > mein Exemplar vor jetzt 30 Jahren gekauft ... Zumindest K&R ist auf pdfdrive zu haben, ebenso Stroustrup. Schäpers wird wohl schwieriger...
Nico W. schrieb: > Ich finde dieses hier noch recht interessant. Habe bisher leider noch > nicht die Zeit gefunden darin länger als ein paar Stunden zu lesen. Das scheint das dedizierte Schicksal dieses Buches zu sein: Es sieht auf den ersten Blick gut aus. Es ist kostenlos. Also speichert man es irgendwo auf der Festplatte unter "G:/vielleicht_spaeter_mal_lesen/ModernC.pdf". Ob es schon jemand wirklich gelesen hat? Ein weiteres Buch, das auf den ersten Blick gut aussieht und im Netz als PDF zu finden ist ist "C Interfaces and Implementations: Techniques for Creating Reusable Software, David R. Hanson, 1997". Das Buch habe ich gelesen, aber es ist verschwendete Zeit. Es erklärt nicht die Prinzipien, nach denen man Interfaces entwirkt, sondern stellt nur die Softwarestruktur, die der Autor verwendet, vor.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.