mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wie aktuell ist K&R C?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Hank (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Klaus R. (klara)


Bewertung
-3 lesenswert
nicht lesenswert
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
von Andreas S. (marais)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Theor (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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. :-)

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hank (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Michael Gugelhupf (Gast)


Bewertung
6 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Egon D. (egon_d)


Bewertung
-3 lesenswert
nicht lesenswert
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.

von Heinz (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Mein Vater kommt mit Stadtplänen von vor 60 Jahren gut klar, mit 
aktuellen Navis hingegen gar nicht.

von Hank (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Uli (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Kanzelbeleuchter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Brian D. Brain (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hank (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Roland F. (rhf)


Bewertung
0 lesenswert
nicht lesenswert
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

von Roland F. (rhf)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Hank (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Egon D. (egon_d)


Bewertung
-1 lesenswert
nicht lesenswert
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".

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@ 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.

von georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Dumdi D. (dumdidum)


Bewertung
0 lesenswert
nicht lesenswert
Theor schrieb:
> Ja. Eine Buch, dass C11 beschreibt bietet gewisse Vorteile

Und welches C11 Buch ist so gut wie das KR Ansi Buch?

von Alexander S. (alesi)


Bewertung
0 lesenswert
nicht lesenswert
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.

von P. S. (namnyef)


Bewertung
0 lesenswert
nicht lesenswert
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
von Kanzelbeleuchter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Walter T. (nicolas)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Kanzelbeleuchter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Kanzelbeleuchter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
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 ....

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

von Jens N. (midibrain)


Bewertung
0 lesenswert
nicht lesenswert
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

von Hank (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Roland F. (rhf)


Bewertung
0 lesenswert
nicht lesenswert
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

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
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?

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Walter T. (nicolas)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dirk B. (dirkb2)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Yalu X. (yalu) (Moderator)


Bewertung
4 lesenswert
nicht lesenswert
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:

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 :)

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Uli (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Egon D. (egon_d)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Walter T. (nicolas)


Bewertung
0 lesenswert
nicht lesenswert
Ging es nicht darum, einen würdigen Nachfolger für K&R als Lehrbuch zu 
finden, das moderne Sprachkonstrukte unterstüzt?

von Egon D. (egon_d)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Udo K. (udok)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Kanzelbeleuchter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Egon D. (egon_d)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Kanzelbeleuchter (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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

von Frank M. (ukw) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

von Egon D. (egon_d)


Bewertung
2 lesenswert
nicht lesenswert
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... :)

von Dirk B. (dirkb2)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Udo K. (udok)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?
>

von Walter K. (walter_k488)


Bewertung
0 lesenswert
nicht lesenswert
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

von Yalu X. (yalu) (Moderator)


Bewertung
2 lesenswert
nicht lesenswert
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.

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.

von Egon D. (egon_d)


Bewertung
-1 lesenswert
nicht lesenswert
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!

von Yalu X. (yalu) (Moderator)


Bewertung
4 lesenswert
nicht lesenswert
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
von Dennis S. (eltio)


Bewertung
-4 lesenswert
nicht lesenswert
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

von Yalu X. (yalu) (Moderator)


Bewertung
1 lesenswert
nicht lesenswert
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?

von Egon D. (egon_d)


Bewertung
-1 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Hank (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Theor (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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)

von Udo K. (udok)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Egon D. (egon_d)


Bewertung
1 lesenswert
nicht lesenswert
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... :)

von zitter_ned_aso (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 vom Autor gelöscht.
von Gerhard (Gast)


Bewertung
4 lesenswert
nicht lesenswert
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

von Yalu X. (yalu) (Moderator)


Bewertung
2 lesenswert
nicht lesenswert
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:

Disclaimer: This ``tutorial'' is presented as a historical document, not
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
von C. A. Rotwang (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>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.

von Percy N. (vox_bovi)


Bewertung
-3 lesenswert
nicht lesenswert
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.

von C. A. Rotwang (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Roland F. (rhf)


Bewertung
3 lesenswert
nicht lesenswert
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

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
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)

von Kanzelbeleuchter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
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).

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Kanzelbeleuchter schrieb:
> if (a=42) {

if (42=a) {

und du bekommst einen Compilerfehler.
(Nein, ich nutze diesen Stil nicht.)

von Nico W. (nico_w)


Bewertung
0 lesenswert
nicht lesenswert
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
if ((a=42))

weg.

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.