Hallo, ich interessiere mich sehr für Mikrocontroller und will mich in die Programmiersprache C einarbeiten, im Fokus habe ich ARM. Das Standarwerk für C ist "K&R ANSI C", wie aktuell ist das denn heute noch? Muss ich danach noch weitere Literatur lesen (weil der C-Standard ja nicht eingeschlafen ist, sondern sich weiterentwickelt hat) oder gibt es ein allumfassendes aktuelles Standardwerk? Es Grüßt und dankt Hank
Hank schrieb: > Das > Standarwerk für C ist "K&R ANSI C", wie aktuell ist das denn heute noch? Das dürfte so aktuell sein wie der Stadtplan von Berlin aus dem Jahre 1988. Einige Straßen sind eben in der Zwischenzeit neu hinzugekommen. mfg Klaus
:
Bearbeitet durch User
Klaus R. schrieb: > Das dürfte so aktuell sein wie der Stadtplan von Berlin aus dem Jahre > 1988. Finde ich nicht. Ich habe einen Stadtplan von Berlin von 1985, der heute ziemlich nutzlos ist (wo ist die Clara Zetkin-Strasse?). Das K&R-Buch zum ANSI-C ist dagegen immer noch ein absolut empfehlenswertes Standardwerk, das hervorragend geschrieben und strukturiert ist, absolut didaktisch und (wie ich finde) sogar spannend und amüsant zu lesen. Was danach an Erweiterungen kam, kann jemand, der dieses Buch komplett durchgearbeitet hat, an einem Vormittag locker nachholen. In der Regel empfehle ich die englischen Originale, aber zu diesem Buch gibt es auch eine wirklich gute deutsche Übersetzung. Auch jemand, der eigentlich langfristig zu C++ will, profitiert davon.
Hm. Da das Buch von 1990 stammt (2. Auflage d. dt. Ausgabe - ANSI-C), beschreibt es natürlich nicht die Entwicklungen bis C18 (C11, C99, C90). Die Veränderungen der Sprache seit 1990 sind durchaus bedeutend. Andererseits handelt es sich zum großen Teil um Erweiterungen. Wenn ich das richtig sehe, ist allenfalls die Veränderung von Funktionsdeklaration/-definitionen deutlich verändert worden. Andererseits: Viele heute gängige Compiler (soweit mir bekannt auch gcc) können ANSI-C-Programme verstehen und übersetzen. Weil es eine persönliche Eigenheit ist, ob und wie leicht jemand eine über längere Zeit ablaufende Veränderung einer formalen Definition und deren Anwendung nachvollziehen und bei der praktischen Arbeit damit berücksichtigen kann, ist es schwer zu beurteilen, ob das Buch für Dich sinnvoll ist. Ich kenne Dich ja leider nicht. Es kann als Einstieg in die Sprache zweckmäßig sein, aber das setzt doch eine gewisse Flexibilität voraus, wenn man im vorhinein weiß, dass man letztlich doch auch C18 anwenden will. Wenn Du allerdings schnell in die Lage kommen willst, in der der Gegenwart, in einem gewerblichen Umfeld und/oder im Team zu arbeiten, wird der Anfang mit K&C eine merkliche zeitliche Verzögerung im Lernfortschritt bedeuten. Kurz: Es kommt darauf an, wie flexibel Du geistig bist, wie gut Dein Gedächtnis ist und wozu Du C lernen willst.
Andreas S. schrieb: > Klaus R. schrieb: >> Das dürfte so aktuell sein wie der Stadtplan von Berlin aus dem Jahre >> 1988. > > Finde ich nicht. Ich habe einen Stadtplan von Berlin von 1985, der heute > ziemlich nutzlos ist (wo ist die Clara Zetkin-Strasse?). Sie ist immer noch da. Sie heisst nur anders. :-) > Das K&R-Buch > zum ANSI-C ist dagegen immer noch ein absolut empfehlenswertes > Standardwerk, das hervorragend geschrieben und strukturiert ist, absolut > didaktisch und (wie ich finde) sogar spannend und amüsant zu lesen. Dem stimme ich vorbehaltlos zu. > Was > danach an Erweiterungen kam, kann jemand, der dieses Buch komplett > durchgearbeitet hat, an einem Vormittag locker nachholen. Vielleicht stimmt das. Ich halte das für schwer zu beurteilen, wenn man die fragliche Person nicht kennt. > In der Regel empfehle ich die englischen Originale, aber zu diesem Buch > gibt es auch eine wirklich gute deutsche Übersetzung. Auch jemand, der > eigentlich langfristig zu C++ will, profitiert davon. Auch dem stimme ich zu. --- Ich bin ja nun auch ein alter Sack inzwischen. Und mir unterlaufen immer wieder Verwechslungen zwischen dem "alten" ANSI-C und einer der neueren Varianten. Vielleicht hätte ja ich warten sollen, bis C18 kommt. :-) Ich will nur zu bedenken geben, dass man sich das mal kurz überlegen sollte, ob man mit dem K&R einsteigt. Allerdings hab ich ihn lieb und ich werde ihn nicht hergeben. :-)
Hank schrieb: > Standarwerk für C ist "K&R ANSI C", wie aktuell ist das denn Wenn dein Buch ANSI C bespricht, dann ist das wesentlich aktueller als das steinzeitalte K&R C. Der Betreff des Threads ist sehr unglücklich gewählt. Mit ANSI C kommt man heute noch sehr weit. Mit K&R C nicht.
Theor schrieb: > Ich will nur zu bedenken geben, dass man sich das mal kurz überlegen > sollte, ob man mit dem K&R einsteigt. > > Allerdings hab ich ihn lieb und ich werde ihn nicht hergeben. :-) Dann muss was aktuelleres her. Axel S. schrieb: > Wenn dein Buch ANSI C bespricht, dann ist das wesentlich aktueller als > das steinzeitalte K&R C. Der Betreff des Threads ist sehr unglücklich > gewählt. Mit ANSI C kommt man heute noch sehr weit. Mit K&R C nicht. Das hier scheint recht bekannt zu sein und ist ANSI C, aber auch sehr dick mit 1080 Seiten: https://www.amazon.de/C-Primer-Plus-Developers-Library/dp/0321928423 Eure Meinung? GIbts was vergleichbares dünneres?
Bevor die Verwirrung zu groß wird, die letzte Ausgabe des K&R Buchs von 1988 (deutsche Version von 1990) behandelt ANSI-C und die kann man problemlos empfehlen. Die Erstausgabe vom K&R ist von 1978 und behandelt C wie es damals war. Diese Version von C wird nach dem Buch bezeichnet, K&R C. Das Buch kann man aus historischen Gründen lesen oder wenn man wirklich K&R C warten muss.
Das Schöne an C und C++ ist, dass immer nur neue Sachen hinzugefügt wurden. Alle alten Regeln gelten weiterhin. Es gibt dazu nur ganz wenige Ausnahmen.
Stefan ⛄ F. schrieb: > Das Schöne an C und C++ ist, dass immer nur neue > Sachen hinzugefügt wurden. Alle alten Regeln gelten > weiterhin. Genau. Deswegen lernen wir ja auch alle das Rechnen mit dem Rechenbuch von Adam Ries. Die Regeln sind ja noch genau dieselben wie damals.
Mein Vater kommt mit Stadtplänen von vor 60 Jahren gut klar, mit aktuellen Navis hingegen gar nicht.
Also kann man unterm Strich sagen, dass die ANSI C Version von K&R brauchbar ist, wenn auch nicht ganz aktuell. Somit werde ich mir erstmal das zu Gemüte ziehen, da um den Faktor 5 dünner.
Selbst mein NAVI (3 Jahre alt) kommt gelegentlich nicht klar. Da ist ein Blick vorher auf eine Karte immer hilfreich. Auch hilft es sich vorher gedanken zu machen, das wenn man nach Norden will nicht mittags ständig auf die Sonne zu fährt, das wäre dann nach Süden. So aber mal zurück zum Thema. C ansich hat sich nicht geändert, da ist das alte K&R noch aktuell. Aber es sind einige Aufweichungen aus dem C++ rein gekommen. Beim GCC kann man Sachen machen die nach K&R nicht gehen würden. Auch sind eininge Systemsachen (Prozessor Kram) rein gekommen. Also wenn Du K&R kannst dann bist Du schon mal gut aufgestellt. Alles weitere lernt man mit der Zeit dazu.
Hank schrieb: > Also kann man unterm Strich sagen, dass die ANSI C Version von K&R > brauchbar ist, wenn auch nicht ganz aktuell. Das würde ich mal so unterschreiben. Man muss aufpassen, dass man das Buch "K&R" nicht mit dem C-Standard "K&R" verwechselt. Der C-Standard "K&R" ist hoffnungslos veraltet aber das Buch "K&R" bietet in der zweiten Auflage ja Ansi-C (d.h. C89). Das klingt zwar nach "Anno Tobak", ist aber von C99 und C11 gar nicht so weit entfernt, was den Sprachumfang angeht, insbesondere wenn es um Sprachfeatures geht, die auch auf Mikrocontrollern Sinn machen. C hat sich grundsätzlich in den letzten 30 Jahren nicht großartig geändert, weshalb ich den "K&R" (d.h. das Buch, nicht den C-Standard) für nach wie vor empfehlenswert halte. Den C Primer Plus finde ich ebenfalls sehr gut aber eher im Sinne eines Nachschlagewerks als im Sinne eines Buches, was man von der ersten bis zur letzten Seite durcharbeitet. Es gibt aber zu C wohl kaum eine Frage die im C Primer Plus unbeantwortet bliebe. In diesem Sinne würde ich beides Empfehlen: Den K&R zum "durchlesen und durcharbeiten" und den C Primer Plus um im Detail nachlesen zu können, falls etwas aus dem K&R unklar sein sollte.
Hank schrieb: > Hallo, ich interessiere mich sehr für Mikrocontroller und will mich in > die Programmiersprache C einarbeiten, im Fokus habe ich ARM. Manchen haben immer noch nicht begriffen, das es einen Himmelweiten Unterschied zwischen "C lernen" und "Mikrocontroller (mit C) programmieren lernen" gibt. Weil, letztlich geht es um das "Kennenlernen des Mikrocontrollers" als Vordringlichen Aspekt und erst, wenn man kapiert hat, wozu man die Programmiersprache braucht, kann man anfangen sich praxisorientiert mit der Programmiersprache und ihren Ökosystem (Bibliotheken, Code generatoren, debugger, Documentationstechniken) auseinanderzusetzen. So braucht es die bitorientierten Befehle viel häufiger bei der µC Anwendung als bei einer Handy-App, während objektorientierte Widget-Bastelei fast ausschließlich in GUI-Klassenbibliotheken gebraucht wird. Die C Bücher aus der Mainframe und PC Ära behandeln eher die Nutzung von Betriebssystem/BIOS-Calls oder 'reine' Datenverarbeitungs-algos (Bubble sort, binary search, ...) aber keine µC Alltagskost wie Pin-Toggling oder Hardwaretimer konfiguration, Interrupthandler, etc. pp. Daher ist, wenn der Fokus auf das Beherrschen von hardwarenaher Controllerprogrammierung liegt, von Büchern im Grundton "C für Akademiker" abzuraten. Empfehlenswert sind zuerst dagegen Bücher mit Fokus auf den Controller wie ISBN: 978-9351071754, die dann C eher beläufig behandeln oder einfach benutzen.
Christopher J. schrieb: > C hat sich grundsätzlich in den letzten 30 Jahren > nicht großartig geändert, Das stimmt zwar -- aber auch, wenn sich die Sprache C nicht großartig geändert hat, so hat sich doch die Compilertechnik weiterentwickelt. Folge: Ungefähr 3/4 aller "Optimierungen" und "Kurzschreibweisen" sind überflüssig. > weshalb ich den "K&R" (d.h. das Buch, nicht den > C-Standard) für nach wie vor empfehlenswert halte. Der K&R ist interessant, aber ich lese ihn aus- schließlich als historisches Dokument. Ich lerne dort, welche Gründe es DAMALS für diese oder jene Entwurfsentscheidung gab. Das hat für mich nichts damit zu tun, wie man HEUTE in C programmieren sollte.
The C Programming Language von Kernighan und Ritchie, welches du "K&R ANSI C" nennst, ist in der ersten Auflage über das alte K&R C und in der zweiten dann über das "neue" ANSI C. Dieses Buch hat mir C erst richtig näher gebracht. Ein bisschen Schleifen programmieren kannst du auch ohne. 21st Century C: C Tips from the New School von Klemens fand ich danach sehr lesenswert, weil es allerhand Schnickschnack gezeigt hat was man mit C so machen kann.
Kanzelbeleuchter schrieb: > Daher ist, wenn der Fokus auf das Beherrschen von hardwarenaher > Controllerprogrammierung liegt, von Büchern im Grundton "C für > Akademiker" > abzuraten. Dann besteht doch die Gefahr den "beiläufig verwendeten Code gar nicht zu verstehen. Aus meiner Sicht sollte man das Werkzeug zuerst kennenlernen.
Hank schrieb: > Kanzelbeleuchter schrieb: >> Daher ist, wenn der Fokus auf das Beherrschen von >> hardwarenaher Controllerprogrammierung liegt, von >> Büchern im Grundton "C für Akademiker" abzuraten. > > Dann besteht doch die Gefahr den "beiläufig verwendeten > Code gar nicht zu verstehen. Aus meiner Sicht sollte > man das Werkzeug zuerst kennenlernen. Richtig. Deswegen wäre wichtig zu wissen, ob Du schon programmieren KANNST, d.h. ob Du bereits IRGEND EINE Programmiersprache beherrschst.
Hallo, Hank schrieb: > Aus meiner Sicht sollte man das Werkzeug zuerst kennenlernen. Ich bin der Meinung zuerst sollte man das Problem kennenlernen und sich danach für das entsprechende Werkzeug entscheiden. Aber das ist ein anderes Thema. Mit Kernighan/Ritchie (ANSI C) machst du jedenfalls nichts falsch. rhf
Hallo, Egon D. schrieb: > Das hat für mich nichts damit zu tun, wie man > HEUTE in C programmieren sollte. Wie programmiert man denn HEUTE in C? rhf
Roland F. schrieb: > Ich bin der Meinung zuerst sollte man das Problem kennenlernen und > sich danach für das entsprechende Werkzeug entscheiden. Aber das ist > ein anderes Thema. Es geht um regelungstechnische Dinge wie Regelung von: - Motordrehzahl - Hubgeschwindigkeit (hydr. Zylinder) - Kraft (pneumatische Zylinder) Da ich das ganze hobbymäßig machen will kommt eine industrielle Steuerung nicht in Frage, daher mein Fokus auf ARM und die Programmiersprache C.
Roland F. schrieb: > Egon D. schrieb: >> Das hat für mich nichts damit zu tun, wie man >> HEUTE in C programmieren sollte. > > Wie programmiert man denn HEUTE in C? Wie MAN das macht -- keine Ahnung. Ist mir wurscht. Wie ICH es mache, hatte ich schon geschrieben: Ich ignoriere großzügig sämtliche Hinweise auf irgend- welche "Optimierungen" und "Kurzschreibweisen".
@ Hank Ich denke man kann die bisherigen Beiträge im Sinne Deiner Frage folgendermaßen zusammenfassen: Ja. Man kann den K&R in der ANSI-V Version noch dazu nutzen C zu lernen. Ja. Eine Buch, dass C11 beschreibt bietet gewisse Vorteile. Nein. Für den Hobby-Bereich ist der Unterschied nicht entscheidend. Ja. Es ist richtig, dass die uC-Programmierung einige Besonderheiten aufweist, die in der Anwendungsprogrammierung kaum oder gar keine Rolle spielen. Ja. Es ist aber ebenso richtig, dass die für die uC-Programmierung notwendigen Ausdrucksformen, in jedem (guten) C-Buch (auch im K&R) erklärt sind, dass manche Menschen aber etwas Nachdenken oder einen Anstoß brauchen, um darauf zu kommen, wie es geht. Ich denke, tiefer brauchst Du im Moment nicht zu forschen.
Hank schrieb: > Es geht um regelungstechnische Dinge wie Regelung von: > - Motordrehzahl Un die haben mit K+R wenig zu tun, überhaupt mit C (und anderen Sprachen), da es in C keine Ports gibt um etwa Drehzahlen auszugeben - dafür müssen alle Compiler um controllerspezifische Befehle ergänzt werden, die in der Sprache nicht vorhanden sind. Und dazu noch muss man sich mit eben diesen speziellen Funktionalitäten auseinandersetzen (z.B. wie lese ich die Ist-Drehzahl ein), bevor man dafür ein Programm schreiben kann. Fazit: K+R ist ok, dazu das Datenblatt des beabsichtigten Kontrollers und ev. sonstiger Hardware. Georg
Theor schrieb: > Ja. Eine Buch, dass C11 beschreibt bietet gewisse Vorteile Und welches C11 Buch ist so gut wie das KR Ansi Buch?
Hank schrieb: > Hallo, ich interessiere mich sehr für Mikrocontroller und will mich in > die Programmiersprache C einarbeiten, im Fokus habe ich ARM. Das > Standarwerk für C ist "K&R ANSI C", wie aktuell ist das denn heute noch? > Muss ich danach noch weitere Literatur lesen (weil der C-Standard ja > nicht eingeschlafen ist, sondern sich weiterentwickelt hat) oder gibt es > ein allumfassendes aktuelles Standardwerk? "K&R ANSI C" ist sicher auch heute noch eines der besten Bücher zu C. Wie gut es wirklich ist, merkt man erst bei der 2. o. 3. Lektüre, da einem viele gute Hinweise beim ersten Lesen gar nicht auffallen. Fast jeder Satz ist wichtig. Etwas modernere Bücher (auch schon > 10 Jahre alt) sind z.B. 21st Century C http://shop.oreilly.com/product/0636920025108.do oder C Primer Plus https://www.pearson.com/us/higher-education/program/Prata-C-Primer-Plus-6th-Edition/PGM4399.html?tab=resources Ein gutes Buch für den Einstieg in dt. Sprache ist aus meiner Sicht C als erste Programmiersprache https://link.springer.com/book/10.1007/978-3-8348-9879-1 Da sich das Programmieren von Mikrocontrollern z.T. deutlich vom Programmieren von PCs unterscheidet, sind evtl. auch Bücher mit Bezug zu ARM in Betracht zu ziehen.
Heutzutage mit dem K&R C lernen würde ich bleiben lassen. Vor allem wenn es um Embedded geht. Als historisches Dokument kann man den sich natürlich ins Regal stellen, weil interessant. Mir ist nur leider auch kein "K&R" für modernes (embedded) C bekannt.
:
Bearbeitet durch User
Hank schrieb: > Kanzelbeleuchter schrieb: >> Daher ist, wenn der Fokus auf das Beherrschen von hardwarenaher >> Controllerprogrammierung liegt, von Büchern im Grundton "C für >> Akademiker" >> abzuraten. > > Dann besteht doch die Gefahr den "beiläufig verwendeten Code gar nicht > zu verstehen. Aus meiner Sicht sollte man das Werkzeug zuerst > kennenlernen. C ist aber nicht das Werkzeug, sondern bestenfalls die "Bedienschnittstelle" eines von vielen Werkzeugen in einer ganzen Kette (Präprozessor, (C-)compiler, linker, loader, console, profiler, tracer,...) Und von C muss man eigentlich nur soviel verstehen, um damit Register und bit's in diesen zuweisen resp. auslesen zu können. Der Hauptteil im uC lernen ist IMHO aber die ganzen Register zu kennen die man zuweisen und auslesen muss. (PWM, ADC,UART,I2C,...) Hinzukommem bewährte Techniken in der Ablaufsteuerung wie, Echtzeitfähiger scheduler, Deadlock Auflösung (WDT), Polling versus IRQ, bit banging, calling conventions, library Strukturierung ... Das sind alles wichtige Lernthemen die m.W. nicht im K+R behandelt werden. Dagegen könnte man IMHO die Kapitel 7 - 8 (file IO Unix) eher überfliegen/auslassen statt durchlesen, schon bei Ch. 5 - 6 (pointer/structures) würde ich je nach controller Abstriche machen. http://www2.cs.uregina.ca/~hilder/cs833/Other%20Reference%20Materials/The%20C%20Programming%20Language.pdf
Kanzelbeleuchter schrieb: > Und von C muss man eigentlich nur soviel verstehen, um damit Register > und bit's in diesen zuweisen resp. auslesen zu können. > > Der Hauptteil im uC lernen ist IMHO aber die ganzen Register zu kennen Und ich fürchte, genau aus der Denkweise heraus gibt es tausend "Softwareentwickler", die den Weg von 0 bis zum "ich schreibe etwas auf Display XXX" niedergeschrieben haben. Vernünftige Literatur, wie man von der Hardwareebene auf eine saubere Softwarearchitektur kommt, scheint dagegen Mangelware.
Und ich seh grad, command line options wie -Wall -O2 -lm -I -L werden auch nicht besprochen .. gehören ja auch nicht zum C-Syntax sind aber IMHO dennoch essential um den Compiler kennen zu lernen, nicht nur für embededd programming.
Walter T. schrieb: > Vernünftige Literatur, wie man von der Hardwareebene auf eine saubere > Softwarearchitektur kommt, scheint dagegen Mangelware. Walter T. schrieb: >> Der Hauptteil im uC lernen ist IMHO aber die ganzen Register zu kennen > Vernünftige Literatur, wie man von der Hardwareebene auf eine saubere > Softwarearchitektur kommt, scheint dagegen Mangelware. Naja, da ist das Zitat aber arg verkürzt, danach werden schon "design practices" genannt die zu guten,stabilen Embedded architekturen führen, und die sich der TO neben den Registerzugriffen aneignen sollte. Und ich glaube, im K&R wird keine einzige davon behandelt, weil der sich auf die C-Syntax und nicht auf Software engineering fokussiert. Das 'Software Engineering Institute' wurde ja auch erst 6 Jahre nach der Erstveröffentlichung von K&R gegründet.
Wenn man mich fragen würde .... Dann würde ich sagen: Arduino, Windows und Linux machen das ganz richtig! C und Assembler für die untersten Layer und C++, oder irgendeine andere Verfügbare OOP Sprache, für die Anwendung. Aber mich fragt ja keiner ....
Moin, Kanzelbeleuchter schrieb: > gehören ja auch nicht zum C-Syntax sind aber > IMHO dennoch essential um den Compiler kennen zu lernen, Ja, logischerweise gehoert sowas zur Dokumentation der Toolchain. Und da stehts auch. Man muss es halt lesen moegen... Ich hab den K&R in der 2. deutschen Auflage und fuer die deutsche Uebersetzung wuerd' ich gerne heute noch den Verantwortlichen mit Katzenscheisse bewerfen. "Uebersetzer", "Binder", "Zeichenvektor" - naja, trotzdem hab' ich seither die ein oder andere Zeile C verfasst. Was mich zum eigentlichen Kern des Pudels bringt: Welches Buch jetzt genau, und welche Abart von C genau ist eher wurscht. Programmieren lernt man weniger durch Buecher als durch Angucken von fremdem src und selber scheitern. Gruss WK
Wenn ich das mal auf diese Weise ausdrücken darf: Dieser Disput handelt sozusagen davon, ob man ein bestimmtes Lehrbuch der französischen Sprache benutzt, weil es bestimmte sprachliche Sachverhalte nicht anhand der Situation: "Verkehrsmittel benutzen" behandelt. Statt dessen werden nur "im Cafè etwas bestellen", "sich vorstellen" etc. als Situationen genommen, ansonsten aber alle Wörter (im K&R werden_ natürlich _alle Wörter der Sprache C behandelt - in einem Lehrbuch einer natürlichen Sprache selbstverständlich nicht) und grammatikalischen Zusammenhänge beschrieben. Von den speziellen Phrasen und der sinnvollen Reihenfolge ihrer Äusserung beim Museumsbesuch oder an der Drehmaschine weiß man dann noch nichts, aber man kann Französisch. So ähnlich sehe ich das mit dem K&R. Man kann nach der Lektüre und Übungen C, man kann es nur noch nicht in bestimmten Bereichen anwenden.
Wie bereits geschrieben, ist das Buch (wenn es denn ANSI-C, also C89 behandelt) gut geeignet. Wenn du danach durch bist, solltest du dich allerdings mal auf eine Zusammenfassung der Neuerungen für zumindest C99 und C11 einlassen, denn dort sind ein paar Dinge hinzugekommen, die das Programmieren in C deutlich angenehmer gestalten. Also: - lern C89, K&R ist eine gute Grundlage; - schau dir an, was in C99 dazugekommen ist; - schau dir an, was in C11 dazugekommen ist. Die meisten Unterschiede können dir egal sein, ein paar wirst du wahrscheinlich mögen. ;-)
Abend, ich hab den K&R 2.Ausgabe erst gelesen als ich in C schon erste Dinge konnte und habe gemerkt das ich das Buch ohne jegliche Vorkenntnisse schwer verstanden hätte. Also lieber erst einmal mit einem einfachen Beginnerkurs für C am PC anfangen und den K&R später lesen, schon um ihn zu besitzen ;-) Jens
Was ist denn davon zu halten? https://www.amazon.de/Grundkurs-C-C-Programmierung-verst%C3%A4ndlich-erkl%C3%A4rt/dp/3836241145/ref=sr_1_2?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=2AKQAEPWCSPDS&keywords=c+programmierung&qid=1585090972&sprefix=c+programmier%2Caps%2C348&sr=8-2 Deutsch, halb so dick wie Prata und relativ aktuell.
Hank schrieb: > Was ist denn davon zu halten? Nichts. Das Buch ist unvollständig und taugt noch nicht mal zum Nachschlagen, da das Inhaltsverzeichnis viele Begriffe nicht enthält. Als Lehrbuch meiner Meinung nach ungeeignet. rhf
Egon D. schrieb: > Ich ignoriere großzügig sämtliche Hinweise auf irgend- welche > "Optimierungen" und "Kurzschreibweisen". Hast Du Beispiele? Meinst Du sowas wie *d++=*s++ statt Langversion?
Theor schrieb: > Von den speziellen Phrasen und der sinnvollen Reihenfolge ihrer > Äusserung beim Museumsbesuch oder an der Drehmaschine weiß man dann noch > nichts, aber man kann Französisch. Aber man 'kann' keine 'Drehmaschine' und da ist der Punkt. Auch ein Franzose muss erst eine Zerspannerlehre/Maschineneinweisung absolvieren, damit er sich nicht beim Parlez-vous an der Drehmaschine die Finger vom Handgelenk fetzt. Die hätte es ihm auch weggefetzt, hätte er vorher Spanisch gelernt. Oder Suhaeli. Und genauso funktioniert "Mikrocontroller programmieren". Man muss nicht eine bestimmte Sprache, vielleicht auch noch in einer altertümlichen Variante, lernen um anschliessend mikrocontroller programmieren zu können; so mancher kann zwar C, kann aber nicht programmieren und mikrocontroller schon garnicht. > *d++=*s++ statt Langversion Diese Kryptographie muss man in keiner Variante können. IMHO ist sogar einer der ersten Ratschläge in Literatur für Gutes Programmieren, weder die Kurz-, noch die Langversion sondern die Bibliotheksfunktion (strncpy, memcpy) zu benutzen. https://www.nongnu.org/avr-libc/user-manual/group__avr__string.html
Jede Programmiersprache erlaubt mehr oder weniger schwer lesbare Konstrukte. Um diese zu vermeiden, wird auf meiner Arbeit jeder Quelltext vor der Übergabe an den Betrieb von einem zweiten Entwickler kontrolliert. Unverständlichen Code hauen wir uns dann gegenseitig um die Ohren. Wenn wir in Perl oder C++ programmieren würden, käme das vermutlich (zumindest Anfangs) noch viel öfter vor.
Stefan ⛄ F. schrieb: > Jede Programmiersprache erlaubt mehr oder weniger schwer lesbare > Konstrukte. Jein, es gibt Programmiersprachen, die fast zu einem natursprachlichen und damit verständlichen Syntax zwingen. 'C' dagegen ist unter den Hochsprachen die, die unter Verwendung der Ausrede "Eleganz" zu für Uneingeweihte am schwersten verständlichen Code führt. Wobei wie immer für schwer verständliche Text zuerst der Autor verantwortlich ist und nicht die Sprache. Gut ist daher ein Lehrbuch das diese Verantwortung klar hervorstellt, K&R zähle ich nicht dazu.
Stefan ⛄ F. schrieb: > . Um diese zu vermeiden, wird auf meiner Arbeit jeder > Quelltext vor der Übergabe an den Betrieb von einem zweiten Entwickler > kontrolliert. Für einen Profi-Programmierer stellt sich die Frage oben nicht. Der fragt einfach Kollegen, die schon weiter sind, welches Buch sie genommen haben. Und haben den Vorteil, dass sie bei Fragen zum Buch schon jemanden kennen, der damit auch mal gearbeitet hat. Und bei einem Hobby-Programmierer macht niemand ein Review. Man kann seinen Quelltext open source machen, aber dann wird sowieso von anderen, die gleichviel oder -wenig Ahnung haben, erst einmal alles schlechtgeredet.
C. A. Rotwang schrieb: > noch die Langversion sondern die > Bibliotheksfunktion (strncpy, memcpy) zu benutzen. Gerade strncpy ist eine gefährliche Funktion, da nicht immer der Terminator kopiert wird. Aber seit C11 gibt es ja die _s Funktionen im Standard. Denen gibt man die Größe des Zielbereichs mit und können so Pufferüberläufe feststellen. Darum darf man nicht bei C89 stehen bleiben.
C. A. Rotwang schrieb: > Jein, es gibt Programmiersprachen, die fast zu einem > natursprachlichen und damit verständlichen Syntax zwingen. Sie meinten: BASIC? Sie meinten: COBOL? SCNR.
C. A. Rotwang schrieb: > Jein, es gibt Programmiersprachen, die fast zu einem natursprachlichen > und damit verständlichen Syntax zwingen. Du denkst jetzt wahrscheinlich an Cobol:
1 | MULTIPLY NUMBER-OF-ITEMS BY PRICE-PER-ITEM GIVING TOTAl-PRICE. |
;-) So eine natürlichsprachliche Syntax bringt IMHO bei Programmiersprachen überhaupt keinen Nutzen. Sie hilft allenfalls dabei, dass Leute, die einer Programmiersprache komplett unkundig sind, wenigstens eine grobe Vorstellung davon bekommen, was ein Programm tut. Da diese Leute aber zum Softwareentwicklungsprozess sowieso nichts beitragen, ist das kein erstrebenswertes Ziel. Für Leute, die eine Programmsprache beherrschen, ist zuviel Natursprache eher hinderlich, weil sie oft den Blick auf das Wesentliche verwehrt. Diese Leute kennen i.Allg. zudem mathematische Formelsprache, die ebenfalls nur wenig mit Natursprachen zu tun hat, aber wesentlich geeigneter zur Formulierung technisch-wissenschaftlicher Probleme und Lösungen ist. Die meisten Programmiersprachen wiederum sind mehr oder weniger an die mathematische Formelsprache angelehnt, und das ist gut so. Cobol konnte sich aus gutem Grund nie außerhalb des Bankenwesens durchsetzen. BTW: Beispiele dafür, dass natürliche Sprachen nicht unbedingt Verständlichkeit garantieren, zeigen immer wieder sehr deutlich Anfragen und Beiträge hier im Forum, wo einem beim Durchlesen außer einem "Häh?" überhaupt nichts einfällt :)
A. S. schrieb: > Egon D. schrieb: >> Ich ignoriere großzügig sämtliche Hinweise auf irgend- >> welche "Optimierungen" und "Kurzschreibweisen". > > Hast Du Beispiele? Wenige. Ich lerne ja selbst noch. > Meinst Du sowas wie *d++=*s++ statt Langversion? Ja, so diese Richtung -- aber nicht nur. Fast die ganze Seite 56 befasst sich z.B. mit dem Problem, was passieren kann, wenn man mehrere if und else kombiniert. Häh?! Ich setze -- MISRA-konform und wie aus Tcl gewohnt -- bei allen Steueranweisungen immer geschweifte Klammern und kann (hoffentlich) die Seite 56 ignorieren.
Programmieren hat erstmal nichts mit einer Programiersprache zu tun, die ist nur mittel zum Zweck. Genauso wie eine IDE oder ein Comandozeilen System mit MAKE. C ist nicht unsicherer oder sonstwas wie Andere auch, man kann mit jeder Programiersprache Mist machen. Es geht hier aber um die alten Bücher und das Wissen dadrin hat sich bis heute nicht geändert, auch wenn inzwischen viele Erweiterungen dazu gekommen sind. Wenn man den alten Kram kann, dann kann man auch die neuen Sachen sehr schnell.
Yalu X. schrieb: > Diese Leute kennen i.Allg. zudem mathematische > Formelsprache, Mathematische Grundbildung ist beim Lernen von C eher hinderlich. Man beginnt sich dann nämlich zu fragen, wieso man an bestimmten Stellen "&&" schreiben muss, wenn dort logisch ein "if" hingehört.
Uli schrieb: > Es geht hier aber um die alten Bücher und das > Wissen dadrin hat sich bis heute nicht geändert, Das Wissen nicht -- aber seine Relevanz: Sie hat abgenommen.
Egon D. schrieb: > Mathematische Grundbildung ist beim Lernen von C eher hinderlich. Mit dem Argument ist beliebiges Vorwissen für das Lernen neuen Wissens hinderlich, denn es könnte ja Kollisionen geben. Das hat nichts mit C oder Mathematik im Speziellen zu tun.
Ging es nicht darum, einen würdigen Nachfolger für K&R als Lehrbuch zu finden, das moderne Sprachkonstrukte unterstüzt?
Walter T. schrieb: > Ging es nicht darum, einen würdigen Nachfolger > für K&R als Lehrbuch zu finden, Ja. > das moderne Sprachkonstrukte unterstüzt? Weiss nicht. Ich bin nicht sicher, wo der Fokus liegt. Meiner Meinung nach wäre schon viel gewonnen, wenn mal ausgemistet und aller unnützer Ballast heraus- geworfen würde. Eine ganze Seite lang zu diskutieren, welches if zu welchem else gehört, wenn sich das ganz leicht eindeutig ausdrücken lässt, indem man geschweifte Klammern setzt -- das ist einfach unnütz. Und wenn die ganzen nutzlosen Hinweise "... können auch weggelassen werden..." wegfielen, wäre das Buch nochmal 5 Seiten dünner. Wer die Feinheiten wissen will, soll im Standard nachgucken. Einem Anfänger hilft das nichts dabei, zuverlässige Programme zu schreiben.
Egon D. schrieb: > Weiss nicht. > Ich bin nicht sicher, wo der Fokus liegt. Meiner > Meinung nach wäre schon viel gewonnen, wenn mal > ausgemistet und aller unnützer Ballast heraus- > geworfen würde. > > Eine ganze Seite lang zu diskutieren, welches if > zu welchem else gehört, wenn sich das ganz leicht > eindeutig ausdrücken lässt, indem man geschweifte > Klammern setzt -- das ist einfach unnütz. Hast du das Buch überhaupt gelesen? Es gibt kein Lehrbuch, dass C in so verständlicher, einfacher und kompakter Form erklärt. Mir kommt vor, wir verblöder (hier) immer mehr.
Uli schrieb: > C ist nicht unsicherer oder sonstwas wie Andere auch, man kann mit jeder > Programiersprache Mist machen. Na, da gibt's welche, wo das ganz schön schwierig, bzw. deutlich schwieriger als in C ist. Ada und Modula II würden mir z.B. einfallen.
Udo K. schrieb: > Egon D. schrieb: >> Weiss nicht. >> Ich bin nicht sicher, wo der Fokus liegt. Meiner >> Meinung nach wäre schon viel gewonnen, wenn mal >> ausgemistet und aller unnützer Ballast heraus- >> geworfen würde. > Es gibt kein Lehrbuch, dass C in so verständlicher, einfacher > und kompakter Form erklärt. Genau das ist das Problem, das Buch erklärt die Programiersprache C, aber weniger das (Mikrocontroller-) Programmieren mit C.
Udo K. schrieb: >> Eine ganze Seite lang zu diskutieren, welches if >> zu welchem else gehört, wenn sich das ganz leicht >> eindeutig ausdrücken lässt, indem man geschweifte >> Klammern setzt -- das ist einfach unnütz. > > Hast du das Buch überhaupt gelesen? Welche alternative Erklärung hast Du für mein zuverlässiges Wissen, dass sich nahezu die ganze Seite 56 mit m.E. unnützen Betrachtungen zu "if" und "else" aufhält? Glaubst Du, ich hätte bei der Telefonauskunft angerufen? > Es gibt kein Lehrbuch, dass C in so verständlicher, > einfacher und kompakter Form erklärt. Dir scheint die bittere Ironie dieser Tatsache nicht aufzufallen. > Mir kommt vor, wir verblöder (hier) immer mehr. Ja, mir auch. Allerdings wohl aus anderen Gründen als Dir.
Moin, Egon D. schrieb: > Welche alternative Erklärung hast Du für mein > zuverlässiges Wissen, dass sich nahezu die ganze > Seite 56 mit m.E. unnützen Betrachtungen zu "if" > und "else" aufhält? Nun, ich denke mal, die Herren Kernighan und Ritchie werden schon ihre Gruende dafuer haben, eine gaaaaaanze Seite lang sich und dich mit solchen Betrachtungen "aufzuhalten". Ich wuerde denen mal vertrauen. Aber auch wenn nicht: Der Vorteil eines Buchs ist der wahlfreie Zugriff... Gruss WK
Dergute W. schrieb: > Moin, > > Egon D. schrieb: >> Welche alternative Erklärung hast Du für mein >> zuverlässiges Wissen, dass sich nahezu die ganze >> Seite 56 mit m.E. unnützen Betrachtungen zu "if" >> und "else" aufhält? > > Nun, ich denke mal, die Herren Kernighan und Ritchie werden schon ihre > Gruende dafuer haben, eine gaaaaaanze Seite lang sich und dich mit > solchen Betrachtungen "aufzuhalten". Ja der Grund war, die Herren sind Scherzkekse und haben sich mit C einen Hoax geleistet, der leider ernster genommen wurde als er gemeint war: https://www.gnu.org/fun/jokes/unix-hoax.html
Kanzelbeleuchter schrieb: > Ja der Grund war, die Herren sind Scherzkekse und haben sich mit C einen > Hoax geleistet, der leider ernster genommen wurde als er gemeint war: > https://www.gnu.org/fun/jokes/unix-hoax.html Dieses Märchen ist fast älter als C selbst.
Dergute W. schrieb: > Egon D. schrieb: >> Welche alternative Erklärung hast Du für mein >> zuverlässiges Wissen, dass sich nahezu die ganze >> Seite 56 mit m.E. unnützen Betrachtungen zu "if" >> und "else" aufhält? > > Nun, ich denke mal, die Herren Kernighan und > Ritchie werden schon ihre Gruende dafuer haben, > eine gaaaaaanze Seite lang sich und dich mit > solchen Betrachtungen "aufzuhalten". Naja... genau das ist doch der Diskussionspunkt: Sind die Gründe, die sie im Jahre 1988 hatten, das Kapitel hineinzuschreiben, im Jahre 2020 noch hinreichend, es zu lesen? Ich kann die Frage nicht beantworten, denn ich kenne ihre Gründe ja nicht. "Ist für das Schreiben korrekter Programme not- wendig" kann schonmal nicht der Grund sein, soviel lässt sich mit Sicherheit sagen -- die dort geschilderten Probleme lassen sich nämlich durch das Verwenden geschweifter Klammern komplett vermeiden. Was also war der Grund? > Ich wuerde denen mal vertrauen. Aber auch wenn > nicht: Der Vorteil eines Buchs ist der wahlfreie > Zugriff... Naja, auf Informationen, die nicht enthalten sind, kann man nicht wahlfrei zugreifen... :)
Egon D. schrieb: > "Ist für das Schreiben korrekter Programme not- > wendig" kann schonmal nicht der Grund sein, soviel > lässt sich mit Sicherheit sagen -- die dort > geschilderten Probleme lassen sich nämlich durch > das Verwenden geschweifter Klammern komplett > vermeiden. > > Was also war der Grund? Sie wollten auf elseif (elsif elif) verzichten und fanden das Einrücken zwischen else und if hässlich. Warum, kann ich dir nicht sagen.
Egon D. schrieb: > Naja... genau das ist doch der Diskussionspunkt: > Sind die Gründe, die sie im Jahre 1988 hatten, > das Kapitel hineinzuschreiben, im Jahre 2020 noch > hinreichend, es zu lesen? Offensichtlich sind viele hier der Meinung, dass dem so sei. Offensichtlich bist du der Meinung, dass dem nicht so sei. Dennoch tust du es, vermutlich um dir eine eigene Meinung bilden zu können. Vorbildlich. Das alles ändert aber nichts daran, dass C auch im Jahre 2020 seine Ursprünge in den späten 70ern nicht verleugnen kann. Wenn man sämtliche alten Zöpfe abschneiden und C einmal grundlegend sanieren würde, dann wäre das vermutlich anders - aber das wird vorerst nicht geschehen. Und die Annahme, dass ein über 30 Jahre altes Buch die relevanten Feinheiten in der aktuellen Anforderung des speziellen Lesers abbilden kann, ist natürlich sowieso daneben. Irgendwo liegt hier eine PDF mit Dokumentation zu UNIX V7 herum. Vieles davon ist selbstverständlich heutzutage überholt und irrelevant; aber die Grundideen werden klar und deutlich erklärt, mitsamt ihren Vor- und Nachteilen (soweit damals bekannt) und für eine Leserschaft ganz ohne Vorkenntnisse. Moderne Bücher tendieren dazu, solche Gedankengänge lapidar unter "das war vor 30 Jahren relevant, daher gibt es noch ein paar zusätzliche Details, auf die wir aber nicht eingehen können" abzuhandeln. Einerseits, weil die Thematik wesentlich umfangreicher ist, andererseits, weil es für die Benutzung nicht notwendig ist. Und das ist die Crux: Willst du ein Buch, in dem drinsteht, wie etwas funktioniert, oder willst du ein Buch, in dem drinsteht, wie du es benutzt? Das Buch von K&R gehört zur ersten Kategorie.
Im Anhang der K&R Auszug zum Else-IF. Da ist kein Satz überflüssig, oder unklar ausgedrückt. Alles ist in einfachem Englisch auf den Punkt genau ausgedrückt. Die richtige Seite ist übrigens 50 und nicht 56. Der TE kann anhand der drei Seiten ja selbst feststellen, ob der K&R für ihn geeignet ist. Es ist ja eh lächerlich, was hier Zeit verschwendet wird, die hätte ich früher genutzt, und wäre schon durch das erste Kaptitel durch. Und was uC betrifft: Seit Arm Cortex M3 gibt es kaum noch Gründe irgendetwas in Assembler zu schreiben. C reicht für 99% der Aufgaben aus, die restlichen 1% lassen sich mit der CMSIS Bibliothek erledigen. Egon D. schrieb: > Udo K. schrieb: > >>> Eine ganze Seite lang zu diskutieren, welches if >>> zu welchem else gehört, wenn sich das ganz leicht >>> eindeutig ausdrücken lässt, indem man geschweifte >>> Klammern setzt -- das ist einfach unnütz. >> >> Hast du das Buch überhaupt gelesen? > > Welche alternative Erklärung hast Du für mein > zuverlässiges Wissen, dass sich nahezu die ganze > Seite 56 mit m.E. unnützen Betrachtungen zu "if" > und "else" aufhält? > > Glaubst Du, ich hätte bei der Telefonauskunft angerufen? >
Ich finde ebenfalls, dass die K&R 2. Ausgabe mit ANSI C noch immer brauchbar und auch empfehlenswert ist - dazu natürlich entsprechende ergänzende Literatur. Ein schönes Beispiel für ein wirklich grottenschlechtes C Buch wäre dann: „C von A bis Z“ von Jürgen Wolf
Egon D. schrieb: > Was also war der Grund? Möglicherweise folgender: In Ritchies "C Reference Manual" (eine der ersten Sprachdefinitionen von C) wird das Dangling-Else-Thema in einem einzigen Satz abgehandelt:
1 | As usual the ‘‘else’’ ambiguity is resolved by connecting an else with |
2 | the last encountered elseless if. |
Viel mehr gibt es dazu eigentlich auch nicht zu sagen. Vermutlich wurde dieser Satz aber von einigen Lesern übersehen oder nicht richtig verstanden, was Kernighan und Ritchie zum Anlass nahmen, in ihrem Buch "The C Programming Language" (schon in der ersten Auflage) das Thema genauer zu erläutern und mit Beispielen zu ergänzen. Das mag dem einen oder anderen als unnötiger Ballast erscheinen. Trotz dieses Ballasts ist der K&R aber nach wie vor das mit Abstand dünnste und dennoch vollständige Lehrbuch für C. Also was soll's? Man kann ja die Stelle etwas schneller überlesen, wenn man meint, die Sache schon verstanden zu haben.
Yalu X. schrieb: > Egon D. schrieb: >> Was also war der Grund? > > Möglicherweise folgender: > > In Ritchies "C Reference Manual" (eine der ersten > Sprachdefinitionen von C) wird das Dangling-Else-Thema > in einem einzigen Satz abgehandelt: > > As usual the ‘‘else’’ ambiguity is resolved by > connecting an else with the last encountered elseless > if. > > Viel mehr gibt es dazu eigentlich auch nicht zu sagen. > > Vermutlich wurde dieser Satz aber von einigen Lesern > übersehen oder nicht richtig verstanden, was Kernighan > und Ritchie zum Anlass nahmen, in ihrem Buch "The C > Programming Language" (schon in der ersten Auflage) > das Thema genauer zu erläutern und mit Beispielen zu > ergänzen. Offenbar bin ich entschieden zu dumm. Ich verstehe zwar Deine Worte, aber ich erkenne den Sinn dahinter nicht: Es ist doch absolut unnötig (außer als abschreckendes Beispiel), detailiert das Verhalten das Compilers beim AUFTRETEN einer Mehrdeutigkeit zu erklären, wenn ich diese Mehrdeutigkeit einfach durch Ändern der Block- struktur, d.h. durch Setzen von geschweiften Klammern VERMEIDEN kann! Diese Information steht ja sogar in einem gemurmelten Nebensatz da -- dennoch zieht sich die Abscheu vor geschweiften Klammern durch alle Beispiele des Buches. Ich meine... ich erkläre ja auch nicht, wieviele unterschiedliche Rauchfahnen ein Transistor im Kurz- schlussfall beim Durchbrennen erzeugen kann, wenn sich der Kurzschluss mit einem simplen Längswiderstand verhindern lässt! Man beschreibt doch nicht zehn Wege, wie es schiefgehen kann, wenn es EINEN Weg gibt, das Schiefgehen zuverlässig zu verhindern!
Egon D. schrieb: > Es ist doch absolut unnötig (außer als abschreckendes > Beispiel), detailiert das Verhalten das Compilers beim > AUFTRETEN einer Mehrdeutigkeit zu erklären, wenn ich > diese Mehrdeutigkeit einfach durch Ändern der Block- > struktur, d.h. durch Setzen von geschweiften Klammern > VERMEIDEN kann! Ein If-Else-Konstrukt ohne geschweifte Klammern ist nun einmal korrekte Syntax. Deswegen sollte man den Leser nicht im Unklaren darüber lassen, was bei der Verwendung genau dieser Syntax geschieht. Egon D. schrieb: > Ich meine... ich erkläre ja auch nicht, wieviele > unterschiedliche Rauchfahnen ein Transistor im Kurz- > schlussfall beim Durchbrennen erzeugen kann, wenn > sich der Kurzschluss mit einem simplen Längswiderstand > verhindern lässt! Das ist etwas anderes: Ein Transistor, der zu rauchen beginnt, wird offensichtlich außerhalb seiner Spezifikationen betrieben. Da muss das genaue Verhalten nicht weiter spezifiziert werden. Ein If-Else ohne geschweifte Klammern liegt aber innerhalb der Spezifikation. PS: Nach deiner obigen Begründung sollte das Buch auch keine Schleifen mit while und for beschreiben, denn man kann diese komplizierten Konstrukte ganz leicht vermeiden, indem man stattdessen eine Kombination aus if und goto verwendet ;-)
:
Bearbeitet durch Moderator
Hank schrieb: > Also kann man unterm Strich sagen, dass die ANSI C Version von K&R > brauchbar ist, wenn auch nicht ganz aktuell. Somit werde ich mir erstmal > das zu Gemüte ziehen, da um den Faktor 5 dünner. "Nicht ganz aktuell" ist ein herrlicher Euphemismus für "völlig veraltet". Warum um aller Welt will man sich DEN Programmierstil heute noch aneignen? Um sich lächerlich zu machen? scnr
Dennis S. schrieb: > Warum um aller Welt will man sich DEN Programmierstil heute > noch aneignen? Um sich lächerlich zu machen? Was ist denn an diesem Programmierstil so lächerlich bzw. signifikant anders als bei dem heute gepflegten?
Yalu X. schrieb: > Egon D. schrieb: >> Es ist doch absolut unnötig (außer als abschreckendes >> Beispiel), detailiert das Verhalten das Compilers beim >> AUFTRETEN einer Mehrdeutigkeit zu erklären, wenn ich >> diese Mehrdeutigkeit einfach durch Ändern der Block- >> struktur, d.h. durch Setzen von geschweiften Klammern >> VERMEIDEN kann! > > Ein If-Else-Konstrukt ohne geschweifte Klammern ist nun > einmal korrekte Syntax. Deswegen sollte man den Leser > nicht im Unklaren darüber lassen, was bei der Verwendung > genau dieser Syntax geschieht. Richtig -- aber dafür genügt, wie Du ja oben selbst demonstrierst, ein einziger Satz. >> Ich meine... ich erkläre ja auch nicht, wieviele >> unterschiedliche Rauchfahnen ein Transistor im Kurz- >> schlussfall beim Durchbrennen erzeugen kann, wenn >> sich der Kurzschluss mit einem simplen Längswiderstand >> verhindern lässt! > > Das ist etwas anderes: Ein Transistor, der zu rauchen > beginnt, [...] Missverständnis. Es ging mir nicht um den Transistor, sondern um den -- funktional überflüssigen -- Schutzwiderstand. Airbags, Sicherheitsgurte, Sicherungen, Schutzleiter... alles funktional überflüssige Dinge. Trotzdem werden sie eingebaut. Nur C-Programmierern ist nicht beizubringen, dass sie zur Sicherheit einfach ein paar "überflüssige" geschweifte Klammern setzen und so vielem Ärger aus dem Weg gehen. > PS: Nach deiner obigen Begründung sollte das Buch > auch keine Schleifen mit while und for beschreiben, > denn man kann diese komplizierten Konstrukte ganz > leicht vermeiden, indem man stattdessen eine > Kombination aus if und goto verwendet ;-) ??? Wer bist Du, und was hast Du mit Yalu gemacht?
Egon D. schrieb: > Richtig -- aber dafür genügt, wie Du ja oben selbst > demonstrierst, ein einziger Satz. Richtig -- und ein einziger Satz zu einem Thema in einem Buch würde von dir vermutlich ebenso angeprangert, weil die Problematik nicht hinreichend erklärt wurde. Wenn du eine so förmliche Herangehensweise möchtest, dass ein einzelner Satz normativ ausreicht, dann solltest du vermutlich ausschließlich den Standard selbst als Lernmaterial benutzen.
Egon D. schrieb: > Offenbar bin ich entschieden zu dumm. Ganz sicher nicht. Es fehlt wohl nur an Erfahrung. Auch misra erlaubt es, (iirc) auf die Klammern zu verzichten. Nämlich genau bei else if, solange es ein finales Else gibt. Bei fehlender Erfahrung fällt das gar nicht auf und sieht wie eine spezielle Notation aus.
Wow ich muss mich für die rege Beteiligung am Thema bedanken. Ich werde es mit dem K&R ANSI C versuchen, der ist am dünnsten und die meisten halten es für eine brauchbare Lektüre. 1080 Seiten beim C Primer Plus muss man erstmal verdauen, das braucht schon viel Zeit denke ich. Ich suche einen schnellen Einstieg.
Udo K. schrieb: > Im Anhang der K&R Auszug zum Else-IF. > > [...] > > Die richtige Seite ist übrigens 50 und nicht 56. Nun. In der deutschen Ausgabe sind es die Seiten 54 bis 56. Aber das nur nebenbei. > Der TE kann anhand der drei Seiten ja selbst feststellen, > ob der K&R für ihn geeignet ist. Eben. Und dank der "std"-Option von gcc kann er auch munter in C90 programmieren. > Es ist ja eh lächerlich, was hier Zeit verschwendet wird, > die hätte ich früher genutzt, und wäre schon durch das > erste Kaptitel durch. > > [...] Tja. Es ist eigentlich alles gesagt. Nur noch nicht von jedem. :-) (Karl Valentin)
Theor schrieb: > Tja. Es ist eigentlich alles gesagt. Nur noch nicht von jedem. :-) > (Karl Valentin) Danke für den passenden Spruch, der trifft das Forum hier ziemlich genau :-) Aber wenn der TE wirklich einen schnellen Einstieg sucht, dann gibt es von Kernighan ein C Tutorial mit den wichtigsten Dinge, die man in der Praxis braucht: https://www.lysator.liu.se/c/bwk-tutor.html Ich habe das nur irgendwann überflogen, und in den Bookmarks wiedergefunden, weiss aber nicht wie gut das ist. Leider kann man heute kein Buch mehr verkaufen, dass weniger als 500 Seiten hat... Man sieht es überall in unserer Gesellschaft, Quantität vor Qualität. Selbst Harald Lesch hat inzwischen kapituliert, RIP geliebte 15 Minuten geballte Info.
Theor schrieb: > Udo K. schrieb: >> Die richtige Seite ist übrigens 50 und nicht 56. > > Nun. In der deutschen Ausgabe sind es die Seiten > 54 bis 56. Korrekt. Danke. > Tja. Es ist eigentlich alles gesagt. Nur noch > nicht von jedem. :-) > (Karl Valentin) Das ist jetzt nicht auf Dich gemünzt, aber wer sich daran stört, dass in einem Diskussionsforum Diskussionen stattfinden, sollte vielleicht... nun ja... seine eigenen Erwartungen kritisch hinterfragen... :)
Hank schrieb: > Ich werde es mit dem K&R ANSI C versuchen, der ist am dünnsten und die > meisten halten es für eine brauchbare Lektüre. > 1080 Seiten beim C Primer Plus muss man erstmal verdauen die meisten Programmierer hatten damals eine Ingeneurausbildung und Vorwissen(Assembler und Co.). Und konnten dementsprechend mit diesem Buch klarkommen. Und es war AKTUELL (bzw. es gab nichts anderes)
Beitrag #6194121 wurde von einem Moderator gelöscht.
Auf was noch nicht eingegangen wurde - installier dir einen C-Compiler auf dem PC und lern mit K&R die Grundlagen dort. Da kannst du dann bei Bedarf debuggen oder Print Statements einstreuen um zu sehen, ob dein Programm das richtige tut. Wenn du dann die Grundkonstrukte verstanden hast kannst du auf dem MC weitermachen. Meine 2 Cent Gerhard
Udo K. schrieb: > https://www.lysator.liu.se/c/bwk-tutor.html > > Ich habe das nur irgendwann überflogen, und in den Bookmarks > wiedergefunden, weiss aber nicht wie gut das ist. Schon interessant, aber nicht zum Lernen geeignet:
1 | Disclaimer: This ``tutorial'' is presented as a historical document, not |
2 | as a tutorial. |
Es beschreibt den Stand von C lange vor der ANSI/ISO-Normierung, d.h. insbesondere, dass Funktionsdefinitionen noch – wie auch in der ersten Auflage des K&R – in der alten Syntax ohne Prototypen erfolgen. Diese Syntax ist nicht nur völlig überholt, sondern wird auch im nächsten C-Standard (C2x) komplett wegfallen. PS: Ich sehe gerade, dass die hier die Operatoren +=, -=, *= usw. noch =+, =-, =* usw. heißen. Das wurde schon vor über 40 Jahren geändert. Dieses Tutorial ist für Programmiersprachenarchäologen, aber nicht für Leute, die die Sprache neu erlernen möchten.
:
Bearbeitet durch Moderator
Angehängte Dateien:
>Hallo, ich interessiere mich sehr für Mikrocontroller und will mich in >die Programmiersprache C einarbeiten, im Fokus habe ich ARM. Die Empfehlung aus meiner Handbibliothek, ISBN 3-7723-5599-4 Untertitel: "GNU-Softwaretools zur Programmierung ARM-basierender Systeme" Das erklärt die toolchain, den ARM prozessor, wie man mit C auf Register zugreift,linker, make,JTAG, serielle Schnittstelle, ... also alles was man zu Embedded Programmieren von ARM braucht, die Beispiele sind in C. Was es allerdings nicht erklärt ist die Programmiersprache 'C'. Vorschlag: besorge Dir dieses Buch gebraucht oder aus der Bibliothek und dazu das K&R als pdf aus den Links oben. Lies erst das embedded Buch, dann das C-pdf. Falls Du statt dem englischen Buch ein uraltes deutsches Standardwerk suchst dann das Lehrbuch der DDR-Studenten: Clauß, Fischer: "Programmieren mit C", VEB Verlag Technik, Berlin, 1988, 1990 Schmankerl nebenher, das Buch ist noch Stilsicher mit troff gesetzt, siehe Anhang.
Klaus R. schrieb: > > Das dürfte so aktuell sein wie der Stadtplan von Berlin aus dem Jahre > 1988. Einige Straßen sind eben in der Zwischenzeit neu hinzugekommen. Falls Du den Plan aus dem VEB Tourist Verlag meinen solltest, wäre das ein nettes Understatement.
Percy N. schrieb: >> Das dürfte so aktuell sein wie der Stadtplan von Berlin aus dem Jahre >> 1988. Einige Straßen sind eben in der Zwischenzeit neu hinzugekommen. > > Falls Du den Plan aus dem VEB Tourist Verlag meinen solltest, wäre das > ein nettes Understatement. Ich sag mal so, wer aus DDR Zeiten die Stadtpläne aufgehoben und die Fachbücher weggeworfen hat alles falsch gemacht. Ebenso wer die Brauchbarkeit von Standards mit den Gebrauchswert von DDR-Devotionalien vergleicht.
Yalu X. schrieb: > C. A. Rotwang schrieb: >> Jein, es gibt Programmiersprachen, die fast zu einem natursprachlichen >> und damit verständlichen Syntax zwingen. > > Du denkst jetzt wahrscheinlich an Cobol: Nein, COBOL kenn ich garnicht, da bin ich trotz meines halben Jahrhunderts zu jung dafür. Gemeint ist auch keine einzelne Sprache konkret, da es m.E. einige Sprachentwürfe gibt, für die Nähe zur Natursprachlichkeit" gefordert wurde. So bei ADA respektive VHDL die ja auch vordringlich zur Dokumentation/Spezifikation erfunden worden und bei denen "handfestes Programmieren" Nebenaspekt ist. Für einen deutschen Muttersprachler ist allerdings nicht offensichtlich das englische Schlüsselwerter wie "if .. then .. else" einen Sourcetext "laut vorlesbar" machen. Microsoft hat es geschafft, VBA sogar ins deutsche zu loaklisieren. Über das Ergebniss und seine Porttierbarkeit lässt sich gerne streiten. https://de.wikipedia.org/wiki/Visual_Basic_for_Applications#Beispiel >Für Leute, die eine Programmsprache beherrschen, ist zuviel Natursprache >eher hinderlich, weil sie oft den Blick auf das Wesentliche verwehrt. Naja, sind das nicht die selben Leute die Xtra-Dokumentieren ablehnen, weil "Guter Quelltext ist selbstdokumentierend"?! Unter dem Aspekt, "selbst dokumentierender Code" schneidet IMHO K&R reichlich schlecht ab. Dann viel lieber Pascal.
Hallo, C. A. Rotwang schrieb: > Unter dem Aspekt, "selbst dokumentierender Code" schneidet IMHO > K&R reichlich schlecht ab. Dann viel lieber Pascal. In wie weit da Pascal einen Vorteil haben soll habe ich nie verstanden. rhf
C. A. Rotwang schrieb: > Falls Du statt dem englischen Buch ein uraltes > deutsches Standardwerk suchst dann das Lehrbuch > der DDR-Studenten: Clauß, Fischer: "Programmieren > mit C", VEB Verlag Technik, Berlin, 1988, 1990 Bloß nicht. Das kennt kein ANSI-C. Ich habe sowohl die deutsche Ausgabe des K&R als auch den Clauß/Fischer da; ich verwenden NUR NOCH den K&R.
Falls jemand meinen Clauß/Fischer haben will - ich gebe den gerne gegen Portoerstattung ab. Und wie ich gerade in den Bücherschrank schaue, da wären noch mehr: Polze, "UNIX-Werkzeuge zur Programmentwicklung" Hübener, "MS-DOS" Neu mit Version 4 alle 3 Bücher vom VEB Verlag Technik Berlin etwas aus der Art geschlagen, trotzdem gleiche Kategorie: L.Preuß, "Turbo-C" (1989, B.G. Teubner Stuttgart)
Roland F. schrieb: > In wie weit da Pascal einen Vorteil haben soll habe ich nie verstanden. Dann haste nie nach dem Fehler in der C-Zeile if (a=42) { suchen müssen.
Kanzelbeleuchter schrieb: > Dann haste nie nach dem Fehler in der C-Zeile > if (a=42) { > suchen müssen. Dafür gibt es zum Glück inzwischen Hinweise in der IDE sowie Test-Tools wie lint (und Spotbugs bei Java).
Kanzelbeleuchter schrieb: > if (a=42) { if (42=a) { und du bekommst einen Compilerfehler. (Nein, ich nutze diesen Stil nicht.)
S. R. schrieb: > if (42=a) { > > und du bekommst einen Compilerfehler. Mit -Wall uns -Werror und einem halbwegs modernen Compiler auch. Explizit bekommt man es dann nur durch
1 | if ((a=42)) |
weg.
:
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.