Empfehlenswerte Literatur zum Erlernen von C

[Gerhard H. (Firma: Rentner) (spectro)]

Möchte mal die Frage stellen, welche Bücher zum Erlernen von C für 
Controller-Anwendungen für nicht ganz blutige Anfänger empfehlenswert 
wären.

Ich habe mir AVR-Mikrocontroller  Programmierung in C von Heimo Gaicher 
und Micro-Controller Technik mit AVR , Programmierung in Assembler  und 
C  von Günter Schmitt und Andreas Riedenauer zugelegt, wobei der 
Schwerpunkt des letzteren Werkes eher bei Assembler liegt.
Das Buch von Heimo Gaischer ist schon mal ausgezeichnet aufgebaut.
Der Kurs hier im Mikrocontroller.net ist ja auch sehr gut.
Kurse auf Youtube liegen mir nicht so, ich habe Bücher lieber.

Gibt es von euch ein paar Etzes für andere Bücher?
(Grundlagen-Kenntnisse vorhanden)

[Patrick C. (pcrom)]

Clean Code / Martin
Working effectively with Legacy Code / Feathers
The Pragmatic Programmer / ?
Test Driven Development / Beck

(Sorry alle Englisch)
Nicht nur fuer C, aber die gelernte dinger sind fuer viele 
Programmiersprache nutzlich

Ich habe auch irgendwo ein deutsches buch wo u.a.DoxyGen und C-Unit 
werden besprochen fuer benutzung mit C, kann exacten titel jetzt nicht 
finden

Grusz Patrick aus die Niederlande

[Dergute W. (derguteweka)]

Moin,

Irgendwann bringts mehr, auch mal wirklich selber was zu programmieren 
als das X-te Buch darueber zu lesen.

Gruss
WK

[Gerhard H. (Firma: Rentner) (spectro)]

Das mache ich ja, aber Anregungen aus Fachliteratur können nie schaden 
und man kann nie genug Fachbücher haben, sag ich mal.

Bisher hatte ich äusserst viel mit BASCOM programmiert, z.B. das hier 
zum Spiegel-Parabolisieren (für ein Newton Teleskop):

https://www.youtube.com/watch?v=yOb71qoFlxA&t=2s

Nun versuche ich mich halt in C. Vielleicht komme ich ja auch gut 
weiter.

[Harald W. (wilhelms)]

Gerhard H. schrieb:

> Möchte mal die Frage stellen, welche Bücher zum Erlernen von C für
> Controller-Anwendungen für nicht ganz blutige Anfänger empfehlenswert
> wären.

Wie wärs mit dem Kernighan Ritchie?

[Oliver S. (oliverso)]

Gerhard H. schrieb:
> Das mache ich ja, aber Anregungen aus Fachliteratur können nie schaden
> und man kann nie genug Fachbücher haben, sag ich mal.

In dem Themengebiet hat man lieber ein einziges gutes Buch, als viele 
schlechte, und lieber gar keins, als auch nur ein schlechtes.

Oliver

[Dergute W. (derguteweka)]

Moin,

Harald W. schrieb:
> Gerhard H. schrieb:
>
>> Möchte mal die Frage stellen, welche Bücher zum Erlernen von C für
>> Controller-Anwendungen für nicht ganz blutige Anfänger empfehlenswert
>> wären.
>
> Wie wärs mit dem Kernighan Ritchie?

Ja, den haette ich auch schon fast vorgeschlagen, aber der ist halt imho 
eher fuer C unter unixoiden OS geschrieben, weniger fuer embedded 
Geruempel.
Und ich hab' den nochdazu damals in einer deutschen Uebersetzung 
gekauft, wo's mir im Nachhinein noch die Schuhe auszieht, wie scheisse 
man so ein Standardwerk uebersetzen kann. WTF soll denn ein Binder sein 
oder ein Uebersetzer?
Hoffentlich ist das derweilen besser geworden.

Gruss
WK

[Gerhard H. (Firma: Rentner) (spectro)]

[qote]In dem Themengebiet hat man lieber ein einziges gutes Buch, als 
viele
schlechte, und lieber gar keins, als auch nur ein schlechtes.[/quote]

Ja, ganz richtig! Das ist auch mein Gedankengang, weshalb ich auch die 
Frage gestellt habe.

So gesehen ist wahrscheinlich das Buch von Heimo Gaicher fast ideal, 
vermute ich.
Mir fehlen halt auch die Ideen für brauchbare Anwendungen. Derzeit wäre 
meine einzige Idee eine Verschlusszeitmessung für analoge Kameras, weil 
ich mich viel mit analoger Photographie und Schmalfilm beschäftige 
(arbeite auch selbst alles aus.)
Möglicherweise wäre eine vorläufige Rückkehr zu Arduino sogar der beste 
Weg, um voranzukommen, ich weiss es nicht.
Mit BASCOM möchte ich nicht mehr arbeiten.

[Dergute W. (derguteweka)]

Moin,

Gerhard H. schrieb:
> Mir fehlen halt auch die Ideen für brauchbare Anwendungen.

OK, da werden wohl auch kaum Buecher ueber Programmiersprachen helfen. 
Das ist sowas von dem Kaliber: Habe Loesung (C), suche Problem...
Das Problem hatten hier iirc Leute schon oefter; vielleicht hilft die 
Suchfunktion.


Gruss
WK

[Wilhelm M. (wimalopaan)]

Vergiss C, lerne C++.
Gerade dann, wenn Du noch kein C kannst.

Dieser Ratschlag hat überhaupt gar nichts mit OOP zu tun. Denn C++ ist 
eine Multiparadigmen-Sprache. Du kannst also genauso gut bzw. besser in 
C++ prozedural/imperativ programmieren wie in C. Jedoch sind es die 
kleinen "Goodies", die Dir sehr viel helfen können.

Also Buch: "Der C++-Programmierer", U. Breymann

[Brian Ritchie (Gast)]

Dergute W. schrieb:
>> Wie wärs mit dem Kernighan Ritchie?
>
> Ja, den haette ich auch schon fast vorgeschlagen, aber der ist halt imho
> eher fuer C unter unixoiden OS geschrieben, weniger fuer embedded
> Geruempel.
> Und ich hab' den nochdazu damals in einer deutschen Uebersetzung
> gekauft, wo's mir im Nachhinein noch die Schuhe auszieht, wie scheisse
> man so ein Standardwerk uebersetzen kann. WTF soll denn ein Binder sein
> oder ein Uebersetzer?

Ich würde immer das Standardwerk empfehlen, idealerweise im englischen 
Original. Anschliessend den Stroustroup für C++, aber erst nach etwas 
Praxis in C.
Ein spezifisches embedded-Buch halte ich für pädagogisch verkehrt. C ist 
schon sehr hardwarenah, und es ist wichtiger, sich erstmal mit der 
C-Denkweise und den Datenstrukturen (und den Einschränkungen von C z.B. 
bei mehrdimensionalen Arrays) vertraut zu machen. Was man dann noch 
braucht, um C embedded einzusetzen, kann man auch leicht im Netz finden.

Brian

[Steve van de Grens (roehrmond)]

Ich denke, man kann die Sprache C (oder C++) besser auf einem PC lernen. 
Dafür gibt es auch viel mehr Bücher und kostenlose Tutorials.

Die Speziellen Feinheiten bezüglich Mikrocontroller habe ich nach und 
nach heraus gefunden. Die Doku der avr-libc war dabei besonders 
hilfreich, wie auch Ratschläge dieses Forums.

[Jester (Gast)]

Brian Ritchie schrieb:

> Ich würde immer das Standardwerk empfehlen, idealerweise im englischen
> Original. Anschliessend den Stroustroup für C++, aber erst nach etwas
> Praxis in C.
> Ein spezifisches embedded-Buch halte ich für pädagogisch verkehrt. C ist
> schon sehr hardwarenah, und es ist wichtiger, sich erstmal mit der
> C-Denkweise und den Datenstrukturen (und den Einschränkungen von C z.B.
> bei mehrdimensionalen Arrays) vertraut zu machen. Was man dann noch
> braucht, um C embedded einzusetzen, kann man auch leicht im Netz finden.
>
> Brian

K&R unbedingt (!) im Original. Ich hatte mal eine Übersetzung ins 
Deutsche - und hab sie umgehend entsorgt.

Ich weis schon, man wirft keine Bücher weg und verbrennt sie auch nicht, 
aber in diesem Fall sowie beim Siemens-Datenbuch SAB8080 musste ich 
einfach eine Ausnahme machen.

Sicher findet sich "The C programming Language" auch irgendwo in den 
Tiefen des russischen Webs. Tu dir trotzdem den Gefallen und besorg dir 
eine gedruckte Ausgabe - und dazu eine Anstaltspackung Post-it (R).

Also ein volles AGREE für Brian!

PS: Posit-it - das sind die meist gelben Zettelchen, die man NICHT an 
DuRöhre-Filmchen rankleben kann...

[Jester (Gast)]

PS: Ich würde Dir zur "Second Edition of The C Programming Language" 
raten - und dort auch ruhig mal das Preface lesen, um sich - wie es 
Brian formuliert hat "erstmal mit der C-Denkweise [...] vertraut zu 
machen".

Eine "3rd Edition" kenn ich nicht - und will auch nicht wissen, wer 
daninter steht ...

just my 2ct

[Da Baby [reformed] (Gast)]

C ist schnell erlernt. Nimm ein Online Buch und schaue Code anderer an.

[Falk B. (falk)]

Wilhelm M. schrieb:
> Vergiss C, lerne C++.
> Gerade dann, wenn Du noch kein C kannst.

Im Alter von 74, wo es nur um bissel Spaß im Hobby geht? Naja . . .

[Oliver S. (oliverso)]

Na, gerade dann ;)

Oliver

[Clöser (Gast)]

Harald W. schrieb:
> Wie wärs mit dem Kernighan Ritchie?

Den fand ich damals (zusammen mit den Lösungen) sehr gut!

[Peter K. (Gast)]

Warum nicht Pascal von mikroe?

Ansonsten
C von A-Z.

Wen Du hier fragst ist jedes Buch kacke außer das vom Richie:-)
Aber das ist totaler Quatsch, und ja in JEDEM Buch finden die irgendwas, 
was falsch ist..
Scheiß drauf
Hauptsache 98% sind super erklärt

https://www.amazon.de/dp/3836239736/?coliid=I7C426UQ0028N&colid=1EY8PXVV38K6C&psc=1&ref_=lv_ov_lig_dp_it_im

[Wilhelm M. (wimalopaan)]

Falk B. schrieb:
> Wilhelm M. schrieb:
>> Vergiss C, lerne C++.
>> Gerade dann, wenn Du noch kein C kannst.
>
> Im Alter von 74, wo es nur um bissel Spaß im Hobby geht? Naja . . .

Ja sicher. Und er hat noch Zeit den Stepanov zu lesen ;-)

[HolgerT (Gast)]

https://www.rowohlt.de/buch/helmut-erlenkoetter-c-9783499600746

[Peter K. (Gast)]

AVR Mikrocontroller - Programmierung in C: Eigene Projekte selbst 
entwickeln und verstehen Taschenbuch – 8. Januar 2016


habe ich gerade hier, ist auch super

[Peter K. (Gast)]

Das von Helmut Erlenkötter finde ich ehrlich gesagt eher 
durchschnittlich.
Ich hatte es mir vor kurzen erst angesehen neben C von A-Z das erheblich 
ausführlicher ist und besser erklärt

[Teo D. (teoderix)]

Gerhard H. schrieb:
> Bücher zum Erlernen von C für
> Controller-Anwendungen für nicht ganz blutige Anfänger empfehlenswert
> wären.

So wie ich "nicht ganz blutige Anfänger" interpretiere, würde ich diese 
empfehlen:
https://openbook.rheinwerk-verlag.de/c_von_a_bis_z/

Ist meist recht verständlich geschrieben und man findet recht schnell 
was man sucht.


PS: Ubs.... was solls, einer mehr :)

[P. S. (namnyef)]

Wirklich gute Bücher für Embedded C sind wohl selten. Da kommt man mit 
Leaning By Doing, Google, Youtube, Blogs usw. weiter, denke ich. Am 
besten hangelt man sich an einem echten Projekt entlang. Sonst verliert 
man schnell die Motivation.

"Clean Code" kann ich auch empfehlen, da hier einfach universelle 
Prinzipien gelehrt werden, die fast überall sehr sinnvoll sind.

Ansonsten kann man sich für ne schmale Mark den MISRA-C Standard holen. 
Die Beispiele und "Rationals" sind extrem lehrreich, wenn man schon 
etwas fortgeschrittener ist. Das Preis-Leistungs-Verhältnis ist hier 
ausgezeichnet.

[Gerhard H. (Firma: Rentner) (spectro)]

[quote]AVR Mikrocontroller - Programmierung in C: Eigene Projekte selbst
entwickeln und verstehen Taschenbuch[/quote]

Das von Heimo Gaicher? Das finde ich auch super. Würde ich selbst 
weiterempfehlen.
Gerhard

[Jörg W. (dl8dtl) (Moderator)]

P. S. schrieb:
> Ansonsten kann man sich für ne schmale Mark den MISRA-C Standard holen.

Ach nee, lieber nicht.

MISRA ist gut für Entscheider. Die können dann immer sagen, sie haben 
sich an den Stand der Technik gehalten.

Für Spaß und Hobby darf man gern ordentlich programmieren, aber bei 
solch sturen Regeln vergeht einem der Spaß manchmal doch recht schnell.

@Gerhard: Fang einfach an (hast du ja schon). Die Tutorials hier haben 
zumindest schon mal den Mikrocontroller-Fokus, da bekommst du dann auch 
sowas wie die im anderen Thread genannten Bitmanipulationen erläutert, 
statt dass du dir anfängst, deine Bitmuster als Hex-Zahlen selbst 
zusammenzuschreiben.

[Wilhelm M. (wimalopaan)]

Jörg W. schrieb:
> @Gerhard: Fang einfach an (hast du ja schon).

Und fange nicht auf einem µC an, C oder C++ oder ... lernen zu wollen. 
Mache das erstmal auf dem PC. Das geht viel einfacher, und es gibt da 
auch sehr viele Aufgaben, an den Du Dich versuchen kannst.

Neben den ganzen Büchern, die hier empfohlen werden, lege auch immer die 
Transskription des C/C++- Standards daneben (denn leider gibt es eben 
auch sehr viele sehr schlechte Bücher, Tutorials, etc.):

https://en.cppreference.com/w/

und lese da nach. Denn das ist nun mal die Richtschnur (s.a. die 
Diskussion um Rückgabetyp und Signatur von main(...) im anderen Thread).

[Peter D. (peda)]

Bücher über die C-Grundlagen würde ich keine kaufen. Die Syntaxregeln 
von C sind überraschend wenige und schnell zu lernen. Außerdem kann man 
sie schneller im Internet nachschlagen und auch die Operatoren und deren 
Rangfolge sowie die Funktionen der Standardlibs.
Speziell Für den AVR-GCC findet man auch hier vieles:
https://www.nongnu.org/avr-libc/user-manual/index.html

Was Anfängern die meisten Probleme bereitet, ist die Herangehensweise an 
eine Aufgabe, d.h. der Programmierstil.
Da gibt es viel falsch zu machen:
https://www.tesolva.de/blogpost/quick-and-dirty-oder-doch-lieber-sauber-programmieren

Daher gibt es darüber viele Bücher, z.B.
"Weniger schlecht programmieren"
https://www.amazon.de/Weniger-schlecht-programmieren-Kathrin-Passig/dp/3897215675

[Wilhelm M. (wimalopaan)]

Peter D. schrieb:
> Bücher über die C-Grundlagen würde ich keine kaufen. Die Syntaxregeln
> von C sind überraschend wenige und schnell zu lernen. Außerdem kann man
> sie schneller im Internet nachschlagen und auch die Operatoren und deren
> Rangfolge sowie die Funktionen der Standardlibs.
> Speziell Für den AVR-GCC findet man auch hier vieles:
> https://www.nongnu.org/avr-libc/user-manual/index.html
>
> Was Anfängern die meisten Probleme bereitet, ist die Herangehensweise an
> eine Aufgabe, d.h. der Programmierstil.
> Da gibt es viel falsch zu machen:
> 
https://www.tesolva.de/blogpost/quick-and-dirty-oder-doch-lieber-sauber-programmieren

Wow, meistens bekomme ich hier was auf die Mütze, wenn ich von 
Clean-Code anfange ;-)

Wer mit dem Programmieren angefangen hat, sollte auf jeden Fall den 
Stepanov "Elements of Programming" lesen.

[Steve van de Grens (roehrmond)]

Wilhelm M. schrieb:
> 
https://www.tesolva.de/blogpost/quick-and-dirty-oder-doch-lieber-sauber-programmieren

Bei einem Punkt muss ich aber widersprechen:

"Das Programm sollte in kurze Methoden (= Funktionen) aufgeteilt werden, 
sodass jede Methode möglichst nur eine konkrete Aufgabe erfüllt. Oft 
wird hier als Richtwert eine Anzahl von 4-6 Zeilen genannt."

Die Ermahnung, Funktionen möglichst kurz zu halten ist ja OK, aber 4-6 
Zeilen halte ich für völlig unpraktikabel.

[Teo D. (teoderix)]

Steve van de Grens schrieb:
> Ich weiß nicht, wer diese 4-6 Zeilen nennt, aber das halte ich für
> völlig unpraktikabel.

Theoretiker
Im Schnitt, gut das Doppelte, dürfte wohl eher realistisch sein.

[Jörg W. (dl8dtl) (Moderator)]

Eigentlich genügt es vollkommen, wenn zusammenhängende Codestücke auf 
eine Bildschirmseite passen. Die ist inzwischen durchaus auch schon mal 
etwas länger als nur 24 Zeilen wie noch vor ein paar Jahrzehnten.

Wichtiger als irgendwelche Dogmas ist, dass man sich in klaren 
Strukturen ausdrückt. Für das Beispiel von Gerhards Siebensegmentanzeige 
wäre daher eine Funktion, die jeweils die aktuelle Stelle neu ermittelt 
und ausgibt, sinnvoll. Die kann er dann aktuell aus main() heraus 
aufrufen und simpel ein Delay danach nehmen. Wenn er dann mal soweit 
ist, dass er auch Interrupts versteht, kann er die gleiche Funktion 
einfach aus dem Timerinterrupt heraus aufrufen.

[Jedes Kind coded (Gast)]

Teo D. schrieb:
> Steve van de Grens schrieb:
>> Ich weiß nicht, wer diese 4-6 Zeilen nennt, aber das halte ich für
>> völlig unpraktikabel.
>
> Theoretiker
> Im Schnitt, gut das Doppelte, dürfte wohl eher realistisch sein.

Statt ein LoC-obergrenze für normale function zu nennen, kann man auch 
eine Untergrenze für wahrscheinlich zu lange functionen nennen. Und die 
liegt bei etwa 100 LoC.

> welche Bücher zum Erlernen von C für
> Controller-Anwendungen für nicht ganz blutige Anfänger empfehlenswert
> wären.

ISBN: 978-3897215672
entgegen dem Titel siehen viele Examples nach C aus. Allerdings weniger 
embedded/Controller als Büro-Informatik.

[Peter D. (peda)]

Steve van de Grens schrieb:
> Die Ermahnung, Funktionen möglichst kurz zu halten ist ja OK, aber 4-6
> Zeilen halte ich für völlig unpraktikabel.

Och, das kriege ich schon hin, es gibt aber auch Ausreißer, die deutlich 
länger sind.
Allgemein versuche ich, Funktionen logisch aufzuteilen.
Hier mal ein Beispiel:

static void wd_reset(void)                              // force watchdog to reset the CPU
{
  cli();
  wdt_enable(WDTO_15MS);
  while (1);
}

void cmd_reset(void)
{
  schedule_remove(wd_reset);
  if (!schedule_add_oneshot(wd_reset, TICKS(0.1)))
    wd_reset();                                         // reset if delayed reset failed
  answer_success();
}

void cmd_eeclear(void)
{
  Eepdata.par.crc++;
  eeprom( (uint8_t*)&Eepdata.par.crc, EEPARAM_END - 2, 1, EE_WRITE );
  cmd_reset();                                          // reset after 0.1s
}

Geht natürlich nur bei MCs mit echtem Stack im RAM.
Kleine PICs mit limitiertem Hardwarestack erlauben das nicht. Da sieht 
man deshalb oft den berüchtigten Spaghetticode mit vielen 
fehlerträchtigen Copy&Paste Wiederholungen.

[Peter D. (peda)]

Jörg W. schrieb:
> Wichtiger als irgendwelche Dogmas ist, dass man sich in klaren
> Strukturen ausdrückt.

Die Tips sollte man nicht als Dogma ansehen, sondern als Empfehlung. 
Einzelne Abweichungen sind also erlaubt.

[Teo D. (teoderix)]

Peter D. schrieb:
> Kleine PICs mit limitiertem Hardwarestack erlauben das nicht.

Wie kommst du auf dieses schmale Brett?!
Dass das nicht sooo effizient umgesetzt werden kann, OK aber das man da 
auf Spaghetti-Code ausweichen muss ist schlicht weg BLÖDSINNI³.
Das du die Dinger nicht magst, ist ja OK aber deswegen dummes Zeug 
verbreiten....

[Jodes Kind coded (Gast)]

Peter D. schrieb:
> Steve van de Grens schrieb:
>> Die Ermahnung, Funktionen möglichst kurz zu halten ist ja OK, aber 4-6
>> Zeilen halte ich für völlig unpraktikabel.
>
> Och, das kriege ich schon hin, es gibt aber auch Ausreißer, die deutlich
> länger sind.

Ehrlich? Das ist scheiße, eine Funktion dadurch zu kürzen, das man code 
durch verschachtelte Funktionsaufrufe ersetzt.
 Einen Functionsaufruf ist IMHO auch kein funktionaler 
(informationsverarbeitender) Code sondern simple rumspringerei. man 
könnte auch sagen, da wird garnichts gemacht, da dreht sich nur der 
Programmcounter im kreise ;-)

[Jörg W. (dl8dtl) (Moderator)]

Jodes Kind coded schrieb:
> man könnte auch sagen, da wird garnichts gemacht, da dreht sich nur der
> Programmcounter im kreise

Nicht zwingend. Wenn der Compiler feststellen kann, dass das alles nur 
Eintagsfliegen sind, dann bleibt der erzeugte Code weiter schön linear.

[Jedes Kind coded (Gast)]

Teo D. schrieb:
> Peter D. schrieb:
>> Kleine PICs mit limitiertem Hardwarestack erlauben das nicht.
>
> Wie kommst du auf dieses schmale Brett?!
> Dass das nicht sooo effizient umgesetzt werden kann, OK aber das man da
> auf Spaghetti-Code ausweichen muss ist schlicht weg BLÖDSINNI³.
> Das du die Dinger nicht magst, ist ja OK aber deswegen dummes Zeug
> verbreiten....

was ist daran dumm? Es gibt nun mal Controller, die können 
Unterprogrammaufrufe nur in wenigen Ebenen verschachteln (Bsp im Anhang 
AVR AT90S1200 -> 3 Ebenen) und da sollte man nicht vom unterprogramm ins 
unter-unterprogramm verzweigen.

[Stefan A. (king-crash)]

Jodes Kind coded schrieb:
> ...sondern simple rumspringerei...

Funktionen wahllos klein zu machen halte ich auch für kontraproduktiv, 
aber wenn es sich aus Lesbarkeitsgründen anbietet ist ein Auslagern in 
eine extra Funktion sehr hilfreich. Mit einem "static inline" vor der 
Funktion gibt es dann auch kein Sprung oder andere Nachteile.

[Jedes Kind coded (Gast)]

Jörg W. schrieb:
> Jodes Kind coded schrieb:
>> man könnte auch sagen, da wird garnichts gemacht, da dreht sich nur der
>> Programmcounter im kreise
>
> Nicht zwingend. Wenn der Compiler feststellen kann, dass das alles nur
> Eintagsfliegen sind, dann bleibt der erzeugte Code weiter schön linear.

Du meinst "Inlining"?!
Darauf würde ich mich aber nicht verlassen. Und dann schaut der (C-)Code 
auch nicht sonderlich consitent aus. Im Code ist es (langsamer9 
Unterprogrammaufruf, im Compilat dagegen flottes inlining (wenn die 
Compileroptionen entsprechend stehen).

[Teo D. (teoderix)]

Jedes Kind coded schrieb:
> da sollte man nicht vom unterprogramm ins
> unter-unterprogramm verzweigen.

Das ist was ganz anderes, als geht nicht..... Hier gehts doch um C und 
nicht um Assembler....

[Jörg W. (dl8dtl) (Moderator)]

Stefan A. schrieb:
> Mit einem "static inline" vor der Funktion gibt es dann auch kein Sprung
> oder andere Nachteile.

"static" genügt (bzw. hilft stark – bei LTO wäre nichtmal das nötig).

"inline" ist nur ein Hinweis an den Compiler, kann er ignorieren. 
Andererseits kann er problemlos auch ohne "inline" die Funktionen inline 
erweitern.

[Jedes Kind coded (Gast)]

Stefan A. schrieb:
> odes Kind coded schrieb:
>> ...sondern simple rumspringerei...
>
> Funktionen wahllos klein zu machen halte ich auch für kontraproduktiv,
> aber wenn es sich aus Lesbarkeitsgründen anbietet ist ein Auslagern in
> eine extra Funktion sehr hilfreich.

Gerade Lesbarkeistgründe sprechen IMHO gegen das Auslagern von 
Code-schnipseln/-fragmenten in extra Funktionen.

>Funktionen wahllos klein zu machen halte ich auch für kontraproduktiv,

Ich würde das nicht als "wahllos" beschreiben, sondern als "zwanghaft 
minimal" oder konkret 4-6 Zeilen. Das ist dann wirklich schwerer lesbar.

Oben, das mit der "Bildschirmseite" (also "ohne scrollen alles im 
Blick") ist m.E. die beste Regel für die Länge einer Function .. obwohl 
es sicher auch "Spezies" gibt, die einen 1920-Bildschirm Hochkant 
aufstellen und den Font-size auf 8 stellen um 240 Zielen untereinander 
zu klatschen ;-)

[Jedes Kind coded (Gast)]

Teo D. schrieb:
> Jedes Kind coded schrieb:
>> da sollte man nicht vom unterprogramm ins
>> unter-unterprogramm verzweigen.
>
> Das ist was ganz anderes, als geht nicht..... Hier gehts doch um C und
> nicht um Assembler....

Nö, das ist genau das selbe. Wenn ein Controller eben nur einen 
call-stack von 3 ebenen hat, dann hat er nur 3 ebenene, egal ob in C, 
assembler oder "HeisserScheiß" programmiert.

[Peter D. (peda)]

Jodes Kind coded schrieb:
> Ehrlich? Das ist scheiße, eine Funktion dadurch zu kürzen, das man code
> durch verschachtelte Funktionsaufrufe ersetzt.

Hab ich auch nie behauptet.
Eine Unterfunktion wird entweder an mehreren Stellen benötigt oder führt 
eine klar abgegrenzte Aufgabe aus. Nur aus Jux und Dollerei unterteile 
ich nichts. Es muß schon der Lesbarkeit dienen.
Nur einmal aufgerufene Funktionen werden eh vom Compiler inlined, d.h. 
verbrauchen keinen Stack.

[rbx (Gast)]

Gerhard H. schrieb:
> Gibt es von euch ein paar Etzes für andere Bücher?
> (Grundlagen-Kenntnisse vorhanden)

Also so grundlegend muss man immer darauf hinweisen:
Lernen durch Übung, üben üben üben, Übung macht den Meister.

- K+R, auch wenn die Übersetzung zum Schmunzeln animiert, der Code eher 
nicht.
- Erlenkötter C, angenehm didaktischer Aufbau, man kann auch lernen, wie 
man eine Game-Engine schreibt. Diesbezüglich bräuchte man aber auch 
nicht zu knapp Mathe in Richtung Lineare Algebra. Statistik kann auch 
nicht schaden, oder Assembler.
- Sedgewick, Algorithmen in C

Ja, man könnte mal versuchen, Verschachtelungen, oder Verschattung auf 
der Assemblerebene hinzubekommen.
Man wird mehrere Wege finden, und sich vermutlich auch für Disassemblies 
interessieren.

oder: wer kann der kann:
https://crypto.stanford.edu/~blynn/c/craft.html

oder: man muss (darüberhinaus) schon wollen:
https://bellard.org/tcc/

[Falk B. (falk)]

Teo D. schrieb:
>> Ich weiß nicht, wer diese 4-6 Zeilen nennt, aber das halte ich für
>> völlig unpraktikabel.
>
> Theoretiker
> Im Schnitt, gut das Doppelte, dürfte wohl eher realistisch sein.

Nicht mal das! 12 Zeilen für eine Funktion? Da hab ich ja gerade mal den 
Kopf geschrieben, die lokalen Variablen deklariert und das return 
geschrieben. Vollkommen weltfremd. Meine Funktionen sind irgendwas 
zwischen 5-1000 Zeilen.

[Teo D. (teoderix)]

Jedes Kind coded schrieb:
> Teo D. schrieb:
>> Jedes Kind coded schrieb:
>>> da sollte man nicht vom unterprogramm ins
>>> unter-unterprogramm verzweigen.
>>
>> Das ist was ganz anderes, als geht nicht..... Hier gehts doch um C und
>> nicht um Assembler....
>
> Nö, das ist genau das selbe. Wenn ein Controller eben nur einen
> call-stack von 3 ebenen hat, dann hat er nur 3 ebenene, egal ob in C,
> assembler oder "HeisserScheiß" programmiert.

Hab ich irgendwo behautet, das sich der HW-Stack auf wundersame weise 
vermehrt?! :DDD

[Teo D. (teoderix)]

Falk B. schrieb:
> 12 Zeilen für eine Funktion? Da hab ich ja gerade mal den
> Kopf geschrieben, die lokalen Variablen deklariert und das return
> geschrieben.

Schon klar, nur der Kopf gehört für mich nicht dazu und da dürfte ich 
wohl nicht der Einzige sein. ;)

[Lothar J. (black-bird)]

Hallo Gerhard H.,
mein Rat (als Rentner) an Dich ist auch das, was Peter D. In diesem 
Thread vorgeschlagen hat:

Peter D. schrieb:
> Bücher über die C-Grundlagen würde ich keine kaufen. Die Syntaxregeln
> von C sind überraschend wenige und schnell zu lernen. Außerdem kann man
> sie schneller im Internet nachschlagen und auch die Operatoren und deren
> Rangfolge sowie die Funktionen der Standardlibs.
> Speziell Für den AVR-GCC findet man auch hier vieles:
> https://www.nongnu.org/avr-libc/user-manual/index.html
>
> Was Anfängern die meisten Probleme bereitet, ist die Herangehensweise an
> eine Aufgabe, d.h. der Programmierstil.

Fang einfach an. Nimm ein funktionierendes Code- Beispiel für Deinen 
Controller aus dem Forum und verändere und erweitere es für Deine 
Wünsche, Stück für Stück.
Sind die Regeln oder die Syntax unklar, hilft ein Buch zum 
!Nachschlagen! oder das Internet.

Peter D. hat auch einen wunderbar funktionierenden UART-Code geschrieben 
(findest Du im Forum), mit dem sich einfache Debug-Ausgaben und auch 
umfangreiche Ein- und sonstige Ausgaben (in ein Terminal-Programm auf 
den PC) machen lassen. Von ihm gibt es auch ein sehr gutes Code-Beispiel 
für Taster und Encoder-Eingaben.

Kannst Du verwenden, musst Du aber nicht.

Wenn Du schon soviel, wie beschrieben, auf die Beine gestellt hast, dann 
ist Lernen per Anleitung eines Buches verschwendete Zeit und bringt Dich 
nur minimal weiter.

Blackbird

[Mike J. (linuxmint_user)]

https://de.wikibooks.org/wiki/C-Programmierung

https://openbook.rheinwerk-verlag.de/c_von_a_bis_z/

[Gerhard H. (Firma: Rentner) (spectro)]

Vielen Dank für die Tipps, Lothar!

Gruss, Gerhard

[Alexander S. (alesi)]

Steve van de Grens schrieb:
> "Das Programm sollte in kurze Methoden (= Funktionen) aufgeteilt werden,
> sodass jede Methode möglichst nur eine konkrete Aufgabe erfüllt. Oft
> wird hier als Richtwert eine Anzahl von 4-6 Zeilen genannt."
>
> Die Ermahnung, Funktionen möglichst kurz zu halten ist ja OK, aber 4-6
> Zeilen halte ich für völlig unpraktikabel.

Richtig, bei 4-6 Zeilen pro Funktion sollte man in Forth mit refactoring 
starten bis man bei einer Zeile pro Funktion angekommen ist :-)

Over the Shoulder 1 - Text Preprocessing in Forth, Samuel Falvo II, 
Andreas Wagner
https://www.youtube.com/watch?v=mvrE2ZGe-rs

[Yalu X. (yalu) (Moderator)]

IMHO sollte heutzutage ein C-Buch mindestens den C99-Standard abdecken,
weswegen der K&R leider etwas überholt ist.

Von den neueren Büchern gefallen mir die beiden folgenden ganz gut:

K. N. King, C Programming – A Modern Approach
- C99
- Enthält auch ein kleines Kapitel über hardwarenahes Programmieren
  (Bitgepopel, Zugriff auf Hardwareregister)
- Beschreibt auch recht ausführlich die Aufteilung großer Programme in
  separate Übersetzungseinheiten (Modularisierung)
- Stil: Eher Lehrbuch
- http://knking.com/books/c2/index.html

Peter Prinz, Tony Crawfordm, C in a Nutshell, 2nd Edition
- C11
- Kleine Einführung in GCC und Make
- Stil: Eher Referenzhandbuch
- https://www.oreilly.com/library/view/c-in-a/9781491924174/

[Gerhard O. (gerhard_)]

Hier ist noch ein Buch:
https://www-personal.acfr.usyd.edu.au/tbailey/ctext/ctext.pdf

"An Introduction to the C Programming Language and Software Design"

Von Tim Bailey

[Alexander S. (alesi)]

Gerhard O. schrieb:
> Hier ist noch ein Buch:

... und hier noch eines:

    Notes on Data Structures and Programming Techniques by James Aspnes

    http://cs.yale.edu/homes/aspnes/classes/223/notes.html

[Wilhelm M. (wimalopaan)]

Alexander S. schrieb:
> Gerhard O. schrieb:
>> Hier ist noch ein Buch:
>
> ... und hier noch eines:
>
>     Notes on Data Structures and Programming Techniques by James Aspnes
>
>     http://cs.yale.edu/homes/aspnes/classes/223/notes.html

Besonders gut ist: "7.1 What’s wrong with C". Wobei hier der erste 
genannte Punkt, dass C keine Garbage-Collection hat, der am wenigsten 
wichtigste ist.

[Wilhelm M. (wimalopaan)]

Teo D. schrieb:
> Falk B. schrieb:
>> 12 Zeilen für eine Funktion? Da hab ich ja gerade mal den
>> Kopf geschrieben, die lokalen Variablen deklariert und das return
>> geschrieben.
>
> Schon klar, nur der Kopf gehört für mich nicht dazu und da dürfte ich
> wohl nicht der Einzige sein. ;)

12 Zeilen für die Signatur?
Und warum definierst Du alle lokalen Variablen am Anfang einer Funktion. 
Das ist doch Blödsinn.
Zeig doch mal ein Beispiel von so einem Monster.

[Alexander S. (alesi)]

Gerhard H. schrieb:
> Ich habe mir AVR-Mikrocontroller  Programmierung in C von Heimo Gaicher
> und Micro-Controller Technik mit AVR , Programmierung in Assembler  und
> C  von Günter Schmitt und Andreas Riedenauer zugelegt,

Daneben gibt es auch noch das Buch AVR - Mikrocontroller von Ingo 
Klöckl.
https://www.degruyter.com/document/doi/10.1515/9783110407693/html
Darin wird die Hardware und die Software beschrieben. Der Fokus liegt 
weniger auf dem Erlernen von C, es gibt aber reichlich Beispiele.

Das wurde, glaube ich, noch nicht genannt.

[Stefan F. (Gast)]

Wilhelm M. schrieb:
> Wobei hier der erste genannte Punkt, dass C keine Garbage-Collection
> hat, der am wenigsten wichtigste ist.

Es ist halt ein fundamentaler Unterschied, den man wissen muss wenn man 
damit arbeitet. Aber nicht unbedingt schlecht. Garbage Kollektoren habe 
ihre eigenen Tücken, die man früher oder später schmerzlich kennen 
lernt, wenn man nicht drauf vorbereitet ist.

[Gerhard H. (Firma: Rentner) (spectro)]

Ich habe ein hervorragendes Lehrbuch entdeckt:

"Mikrocontroller programmieren lernen. Einführung in die Programmierung 
von Mikrocontrollern-Vom Programmiergerät bis zu fertigen Projekten" von 
Holger Weiß.
Verwendet wird der ATMega328.
Ideal für Anfänger.
Endlich mal etwas, das wirklich was taugt.

Empfehlenswert!

[Mike J. (linuxmint_user)]

Stefan F. schrieb:
> Es ist halt ein fundamentaler Unterschied, den man wissen muss wenn man
> damit arbeitet. Aber nicht unbedingt schlecht.

Man kann ja auch erlernen seinen Müll mal selbst weg zu räumen.

[Steve van de Grens (roehrmond)]

Ein allgemein gehaltenes Buch über C auf Mikrocontrollern kann es meiner 
Meinung nach gar nicht geben.

Denn diese Programmiersprache war eigentlich für (mindestens) 16 Bit 
Computer mit Betriebssystem gemacht. Deswegen hat in C der normale 
Integer 16 Bit. Einzelne Bits gibt es in C eigentlich nicht. 
Interrupthandler und das Ansprechen von Registern war dem Betriebssystem 
vorbehalten, welches an diesen Stellen vorwiegend in Assembler 
programmiert wurde.

Auf Mikrocontrollern braucht man das alles aber, und zwar vorzugsweise 
direkt in C ohne Assembler Code einbetten zu müssen.

Jeder C Compiler wurde daher abweichend vom Standard C speziell für den 
jeweiligen Mikrocontroller Typ angepasst und bringt entsprechend 
spezifische Erweiterungen/Eigenheiten mit sich.

Wenn man das lernen will, muss man mit einem konkreten 
Mikrocontroller-Typ anfangen. Die klassischen AVR eignen sich dazu sehr 
gut, wie ich meine.

[Jörg W. (dl8dtl) (Moderator)]

Steve van de Grens schrieb:
> Ansprechen von Registern war dem Betriebssystem vorbehalten, welches an
> diesen Stellen vorwiegend in Assembler programmiert wurde.

C war von vornherein dafür gedacht, möglichst große Teile des 
Betriebssystems damit implementieren zu können.

https://www.bell-labs.com/usr/dmr/www/cacm.html

"The preponderance of Unix software is written in the abovementioned C 
language [7]. Early versions of the operating system were written in 
assembly language, but during the summer of 1973, it was rewritten in 
C."

[Wilhelm M. (wimalopaan)]

Steve van de Grens schrieb:
> Interrupthandler und das Ansprechen von Registern war dem Betriebssystem
> vorbehalten, welches an diesen Stellen vorwiegend in Assembler
> programmiert wurde.

Im Gegenteil: Du solltest

https://www.amazon.de/Lions-Commentary-Computer-Classics-Revisited/dp/1573980137/ref=mp_s_a_1_1?adgrpid=69429517417&gclid=Cj0KCQiA54KfBhCKARIsAJzSrdqFogTRdvvEi3b_uSv_eB-FrOMB-khoNvMYSbNUDyzWv0Mo-Qh-G-caAvcHEALw_wcB&hvadid=606880222937&hvdev=m&hvlocphy=9041805&hvnetw=g&hvqmt=e&hvrand=4042124887765880146&hvtargid=kwd-298623509747&hydadcr=12219_2388108&keywords=lions+commentary+on+unix&qid=1675671388&sr=8-1

lesen.

[Alexander S. (alesi)]

Wilhelm M. schrieb:
...
>
> Im Gegenteil: Du solltest
>
> ...
>
> lesen.

Danke für den Link. "A commentary on the Sixth Edition UNIX Operating 
System, with Source Code" gibt es im Internet, u.a. bei archive.org
https://archive.org/details/CommentarySixthEditionUNIX/6thEdLions/mode/2up
Links oben ist auch der Link auf den Source Code (pdf).

Die 6th ed. war für eine PDP-11/40. Unter dem Namen xv6 gibt es eine 
moderne Implementierung für x86 und RISC-V:
"xv6 is a modern reimplementation of Sixth Edition Unix in ANSI C for 
multiprocessor x86 and RISC-V systems. It was created for pedagogical 
purposes in MIT's Operating System Engineering course in 2006."
https://en.wikipedia.org/wiki/Xv6

[Christian B. (casandro)]

Also mir hat sehr geholfen vorher erst mal einen angenehmen Assembler 
(AVR-Risc) gut zu können.
Daraus habe ich folgende wichtige Punkte erlernt:
1. Was der Computer eigentlich macht: C hat keine Abstraktionsebenen die 
Dich vor der Maschine retten. Arrays sind beispielsweise nur Pointer bei 
denen ein "Multiplikationsfakor für den Index" im Compiler verwaltet 
wird. Was daraus folgt wird klar, wenn man schon mal Assembler 
programmiert hat.
2. Dinge die man in C nicht machen sollte tun in Assembler richtig weh: 
Beispielsweise verschachtelte if-Abfragen. So was tut in Assembler 
einfach weh.

C selbst ist dann relativ schnell erlernt. Wenn man von der 
Assemblerseite her kommt sieht man das schnell als Assembler mit jeder 
Menge Komfortfunktionen an.

Dann kommt die Phase in der man dann den Umgang mit diesen angenehmen 
Funktionen kennen lernen sollte. Es mag vielleicht erst mal absurd 
klingen, aber dort kann man von anderen Sprachen lernen. Es gibt da ein 
Erlang-Buch, das mir geholfen hat deutlich lesbareren C-Code zu 
schreiben.

"The Art of UNIX Programming" ist ein Standardwerk für die praktische 
Gestaltung von Programmen. Das ist zwar eigentlich auf UNIX-Systeme 
ausgelegt, man kann daraus aber auch viel für Embedded-Systeme lernen. 
(z.Bsp. dass es sehr häufig sinnvoll ist Textformate zu verwenden)

Dann muss man wissen, was Compiler heute können. Da hilft es wenn man 
sich den Assemblercode ausgeben lässt, den der Compiler erstellt. 
Standardfunktionen sind heute zum Beispiel "Tail-Recursion", was unter 
speziellen Bedingungen rekursive Funktionsaufrufe in Schleifen 
umwandelt. Dadurch kann man, ohne Probleme mit dem Stack, Rekursion 
anstelle von Schleifen verwenden, was unter bestimmten Bedingungen den 
Code sehr viel lesbarer machen kann.

Wichtig ist auch immer: Du programmierst nicht für den Compiler, Du 
programmierst für den der nach Dir den Code lesen muss. Je simpler Dein 
Code ist, je weniger unnötige Sprachelemente Du benutzt, um so leichter 
tut sich der Nächste. Das typische Negativbeispiel ist das typische 
"Hello World" in C++ mit Streams, bei Dem Du erst mal einige Wochen C++ 
lernen musst um es lesen zu können.

[Gerhard O. (gerhard_)]

Christian B. schrieb:
> Wichtig ist auch immer: Du programmierst nicht für den Compiler, Du
> programmierst für den der nach Dir den Code lesen muss.

Das ist man meistens selber;-)

[M. K. (sylaina)]

Gerhard O. schrieb:
> Das ist man meistens selber;-)

Gilt nur für die ersten Tage ;) :D

[Peter D. (peda)]

M. K. schrieb:
> Gerhard O. schrieb:
>> Das ist man meistens selber;-)
>
> Gilt nur für die ersten Tage ;) :D

Gilt besonders, wenn der Kunde Eweiterungen möchte und man sich nach 
einem Jahr wieder reinfitzen muß.
Da zahlt es sich dann aus, wenn man nicht schnell mal eben den 
grausamsten C&P Spaghetticode runtergerotzt hat, sondern schon eine 
Struktur reingebracht hat.

[M. K. (sylaina)]

Peter D. schrieb:
> M. K. schrieb:
>> Gerhard O. schrieb:
>>> Das ist man meistens selber;-)
>>
>> Gilt nur für die ersten Tage ;) :D
>
> Gilt besonders, wenn der Kunde Eweiterungen möchte und man sich nach
> einem Jahr wieder reinfitzen muß.
> Da zahlt es sich dann aus, wenn man nicht schnell mal eben den
> grausamsten C&P Spaghetticode runtergerotzt hat, sondern schon eine
> Struktur reingebracht hat.

[Christian B. (casandro)]

Gerhard O. schrieb:
> Das ist man meistens selber;-)

Richtig, deshalb ist es wichtig, dass selbst der dümmste Mensch den man 
sich vorstellen kann, den Code noch verstehen kann... denn das ist man 
meistens selber. :)

Ich persönlich tendiere dazu, "schwierige" Konstrukte weg zu lassen, 
wenn sie nicht benötigt werden.

Ein Beispiel ist die destruktive Zuweisung auf Variablen. In C kann man 
folgendes machen:

int i=15; //Deklaration von Ganzzahlvariable i mit dem Wert 15
i++; //destruktives Überschreiben des Wertes von i mit 16

Besser, aber noch nicht gut ist da:
i=i+1;

Wobei man häufig sogar ganz darauf verzichten kann, wenn man sein 
Programm sinnvoll strukturiert.

Was ich aus Erlang gelernt habe ist, dass man Eingabevariablen auch 
gleich am Anfang testen kann, also nicht:

void irgendwas(char *s)
{
   if (s!=NULL) {
 ...
   }
}


sondern:
void irgendwas(char *s)
{
   if (s==NULL) return;
...

[Jörg W. (dl8dtl) (Moderator)]

Christian B. schrieb:
> sondern:
> void irgendwas(char *s)
> {
> if (s==NULL) return;
> ...

Dann solltest du nie mit MISRA in Berührung kommen, denn die sind der 
Meinung, dass eine Funktion nur einen einzigen Ausgang haben darf.

Dass das dann zu undurchsichtigem if/else-Spaghetti führt, scheint sie 
nicht weiter zu berühren …

[P. S. (namnyef)]

Jörg W. schrieb:
> Christian B. schrieb:
>> sondern:
>> void irgendwas(char *s)
>> {
>> if (s==NULL) return;
>> ...
>
> Dann solltest du nie mit MISRA in Berührung kommen, denn die sind der
> Meinung, dass eine Funktion nur einen einzigen Ausgang haben darf.
>
> Dass das dann zu undurchsichtigem if/else-Spaghetti führt, scheint sie
> nicht weiter zu berühren …

Den MISRA-Standard (£15!) kann man sich alleine deswegen schon ins Regal 
stellen, damit man nicht den getriggerten KMU-Bastlern, die noch nie in 
ihrem Leben sicherheits- oder missionskritische Firmware geschrieben 
haben, geschweige denn mit IEC 61508 oder ISO 26262 in Berührung 
gekommen sind, glauben schenken muss.

Dann wüsste man z. B. auch, dass die "single point of exit"-Regel 
lediglich "Advisory" ist. Diese Regel also nur eine "Recommendation" 
darstellt, die man nur "as far as reasonable practical" befolgen sollte.

[Jörg W. (dl8dtl) (Moderator)]

P. S. schrieb:
> Dann wüsste man z. B. auch, dass die "single point of exit"-Regel
> lediglich "Advisory" ist.

Das hilft dir nichts, wenn dir die innerbetriebliche Bürokratie dann 
vorschreibt, dass du jegliche Abweichung davon in irgendeinem 
umständlichen Prozess dokumentieren musst. Weil darauf keiner Bock hat, 
wird dann doch lieber wieder Spaghetticode mit viel if / else 
geschrieben, denn darüber beschwert sich keiner der MISRA-Checker. 
Dass man den Mist hinterher gar nicht mehr lesen kann, bewertet kein 
maschineller Test, und MISRA schreibt auch nirgends, dass lesbarer Code 
einem stur die Regeln befolgenden Code zu bevorzugen wäre.

[Tam H. (Firma: Tamoggemon Holding k.s.) (tamhanna)]

Guido Krüger, Programmieren in C
OReilly - Mastering Algorithms in C
Spinellis - Code Reading
Ted Faison - Taking Events to the Limit

Danach je nach Laune entweder mein Buch zu MCUs und/oder
OReilly - AI for Game Developers und OReilly - Physics for Game 
Developers



Alle antiquarisch gut erhaeltlich zuB bei Alibris

[Christian B. (casandro)]

Jörg W. schrieb:
> Dann solltest du nie mit MISRA in Berührung kommen, denn die sind der
> Meinung, dass eine Funktion nur einen einzigen Ausgang haben darf.

Ja, das ist so wie eine "ISO-Zertifizierung" in einem Unternehmen. Das 
dient primär als Zeichen dafür, dass man in so ein Unternehmen nicht 
gehen will.

Solche Regelwerke bringen in der Regel nur "Boxticking" ohne echte 
Sicherheitsvorteile.

[Jörg W. (dl8dtl) (Moderator)]

Christian B. schrieb:
> Das dient primär als Zeichen dafür, dass man in so ein Unternehmen nicht
> gehen will.

Würde ich so nicht sagen.

ISO900x besagt ja nur, dass du definierte (und dokumentierte) Prozesse 
haben musst. Das ist nicht per se schlecht, es ist nur initial etwas 
Aufwand, die Prozesse zu etablieren (ich habe das mal mehr beobachtend 
in einer eher kleinen Firma miterlebt).

Meine Kurzzusammenfassung davon war immer: Wenn bei einem solchermaßen 
bestätigten Prozess einmal Schei*** rauskommt, muss der Prozess 
garantieren, dass immer die gleiche Schei*** rauskommt.

[Gerhard O. (gerhard_)]

Christian B. schrieb:
> Ja, das ist so wie eine "ISO-Zertifizierung" in einem Unternehmen. Das
> dient primär als Zeichen dafür, dass man in so ein Unternehmen nicht
> gehen will.

Das ist nicht immer ihre Schuld. Unsere Kunden bestehen auf ISO 
Zertifikation und das ist eben so.

Wenn man ISO Prinzipien intelligent befolgt, bringt es durchaus 
Vorteile, und dass man sich z.B. darauf verlassen kann, dass die 
Messgeräte kalibriert sind und nützliche Regeln konsistent befolgt 
werden. Es muss nicht unbedingt schlecht sein. Die Einhaltung der selbst 
aufgestellten ISO Prozeduren gibt keine Garantie für Qualität. 
ISO-Regeln machen sie nur konsistent. Abgesehen davon wird das jedes 
Jahr geprüft. Was mich betrifft, finde ich es durchaus ein gutes 
Konzept, solange es intelligent aufgestellt wurde und die Kollegen 
halten sich daran.

Nachtrag: Ich stimme Joerg zu.

[Philipp K. (philipp_k59)]

Also so für das Hobby, ohne jetzt der Pro werden zu wollen,fand ich nach 
nen paar Jahren Autodidakt das Buch "c++ programmieren: c++ lernen" 
schonmal nicht schlecht.

Das hat mir dann ohne langweilig zu werden noch einige Tips und Kniffe 
gezeigt.

Man kann sich natürlich auch direkt nen Wälzer empfohlen von den 
professionellen Informatikern reinziehen, aber das war mir für meine 
Ziele etwas too much.

[Apollo M. (Firma: @home) (majortom)]

Tam H. schrieb:
> Alle antiquarisch gut erhaeltlich zuB bei Alibris

und in der Library Genesis http://libgen.rs/

[Steve van de Grens (roehrmond)]

P. S. schrieb:
> Dann wüsste man z. B. auch, dass die "single point of exit"-Regel
> lediglich "Advisory" ist. Diese Regel also nur eine "Recommendation"
> darstellt, die man nur "as far as reasonable practical" befolgen sollte.

Klingt sinnvoll.

In der Regel bemühe ich mich darum, dass Funktionen nur ein 
erfolgreiches Ende haben (und zwar ganz unten). Aber im Fehlerfall 
dürfen sie auch früher aussteigen.

[Oliver S. (oliverso)]

Jörg W. schrieb:
> Meine Kurzzusammenfassung davon war immer: Wenn bei einem solchermaßen
> bestätigten Prozess einmal Schei*** rauskommt, muss der Prozess
> garantieren, dass immer die gleiche Schei*** rauskommt.

Und dann kommt noch irgend ein Berater, und lässt den Prozess in 
Software giessen. Damit die gleiche Schxxx sehr viel schneller 
rauskommt.

Oliver

[Steve van de Grens (roehrmond)]

Gerhard O. schrieb:
> Unsere Kunden bestehen auf ISO Zertifikation und das ist eben so.

Unsere auch. Deswegen kann ich doch nicht einfach das Handtuch werfen.

[Peter D. (peda)]

Jörg W. schrieb:
> Dann solltest du nie mit MISRA in Berührung kommen, denn die sind der
> Meinung, dass eine Funktion nur einen einzigen Ausgang haben darf.

Man könnte MISRA ja austricksen:

  do
  {
    if ( Errorcase0 )
      break;
    do_something0();
    if ( Errorcase1 )
      break;
    do_something1();
    if ( Errorcase2 )
      break;
    do_something2();
    if ( Errorcase3 )
      break;
    do_something3();
  }
  while( 0 );

Statt break geht auch continue, z.B. wenn man per switch abbrechen will.

[Yalu X. (yalu) (Moderator)]

Peter D. schrieb:
> Man könnte MISRA ja austricksen:
> ...

Auch von mehrfachen Breaks in Schleifenkonstrukten wird in MISRA
abgeraten :)

Mehrfache Returns, mehrfache Breaks und auch Gotos werden in MISRA alle
ähnlich bewertet: Man sollte sie vermeiden, sie sind aber nicht
verboten. Für die Fehlerbehandlung einer längeren Kette von Aktionen
sind oft Gotos zu einem gemeinsamen Ziel ganz praktisch, weil man dann
dort noch eine gemeinsame Abschlussaktion unterbringen kann.

[Philipp K. (philipp_k59)]

Jörg W. schrieb:
> ISO900x besagt ja nur, dass du definierte (und dokumentierte) Prozesse
> haben musst.

Kann bei alten Strukturen in der Firma aber auch auf "Excel Tabellen 
sind nicht mehr zeitgemäß" und zwingende Umstellung auf ein ERP führen.