wiederverwendbare Software in C

Marcus schrieb:

> Es scheint schon ein wenig älter,

ist völlig egal.
C ist ja auch schon älter. Nach 1999 ist da auch nichts dazu gekommen, 
was dir bei der Thematik irgendwie grossartig weiter helfen würde. D.h. 
wenn du den Buch-Stand von 1999 umsetzen kannst, dann bist du in dieser 
Thematik ziemlich 'state of the art' oder zumindest dicht drann.

Die Rezensionen sind ja recht gut.

Und abgesehen davon, würde ich aus dem Hause "Addison-Wesley 
Professional Computing" so ziemlich alles auch unbesehen kaufen.

Das Buch klingt sehr interessant. In welchen Applikationen kommt den 
wiederverwendbare Software vor?  I/O-Module?

Querleser schrieb:
> 50 Kröten dafür? Never. Suchmaschine und trojanerresistenten Browser auf
> einem virenfesten Betriebssystem bemühen...

Naja, und dann viel Spass beim Suchen. Ich denke, wenn man sich wirklich 
ernsthaft mit dem Thema beschäftigen will und es nutzen will haben sich 
die 50 Kröten fix amortisiert.

Noch einer schrieb:
>> wenn man ein konkretes Projekt sinnvoll modularisiert.
>
> Gibt es Bücher, aus denen man so etwas lernen kann? Oder geht das nur
> aus Erfahrung?

Letzten Endes ist vieles davon Erfahrung. Die Suche nach Kochrezepten 
für Kreativität geht in der Informatik regelmässig in die Hose. Aber 
auch anders rum: viele anerkannte Regeln sind von der Form, dass man 
auch im angemessenen Fall die Regel über Bord wirft. Die Frage ist nur: 
was ist 'angemessen'? Womit wir wieder bei Erfahrung sind.

Es hilft allerdings, wenn man anderer Leute Code studiert und sich 
ansieht wie die das gemacht haben. Besonders gut ist es natürlich, wenn 
der Autor dann auch noch erklärt, warum er so manche Designentscheidung 
gemacht hat und warum er sich gegen welche anderen Alternativen 
entschieden hat.

Alle Regeln bzw. Grundgedanken wird man nicht von Anfang an beherzigen 
können, weil man sich die gar nicht merken kann. Zudem ist jeder Fall 
anders gelagert und sei es nur in Details. Womit wir wieder beim Thema 
'Erfahrung' sind.

Ein nicht unwesentlicher Punkt beim Thema Erfahrung sind auch die 
Fehler, die man selber macht.
Es gibt einen alten Spruch: Ein erfahrener Programmierer unterscheidet 
sich von einem unerfahrenen dadurch, dass er alle Design-Fehler, die der 
unerfahrene in den nächsten 10 Jahren machen wird, alle schon mindestens 
einmal gemacht und beseitigt hat.
Das heisst so viel wie: Du musst Fehler machen. Du musst sehen, wie 
sich ein Design-Fehler auswirkt. Du musst dich selbst ein paar mal in 
die Ecke manövriert und dich mühsam wieder aus dieser rausmanövriert 
haben, um in Zukunft den Braten rechtzeitig zu riechen. Kein Handbuch 
kann dir diese Erfahrung geben. Es kann dir Anregungen geben, es kann 
dich bis zu einem gewissen Grad leiten. Es kann dir recht 
offensichtliche Designfehler vorführen und auch das Gegenteil. Aber es 
wird nie so sein, dass du nur dieses eine Buch zu lesen brauchst und 
dann bist du perfekt.

Ich kenn obiges Buch leider nicht, kann Dir aber das "Test-Driven 
Development for Embedded C" von J. Grenning nahe legen. Legt sehr viel 
Wert auf CleanCode und Interface-Driven-Development. Als Interfaces 
werden dabei Funktionspointertypen verwendet - die implementierten 
Funktionen, die diesem Typ entsprechen, werden dann austauschbar gemäß 
dem Strategiemuster. Ich fand's 'nen sehr interessanten Ansatz - ist 
aber letztlich das, was C++ unter der Haube bei den VTables auch macht. 
Wer aber auf reine ANSI-C-Entwicklung angewiesen ist und versuchen 
möchte, Design-Patterns prozedural anzuwenden um SOLIDen Code zu 
produzieren, dem sei das TDD-Buch durchaus zu empfehlen:

http://www.amazon.de/Driven-Development-Embedded-Pragmatic-Programmers/dp/193435662X/ref=pd_sim_14_3?ie=UTF8&refRID=0FMP5QRX2FSFZXE4PFWZ

Also der Klassiker, den man zumindest mal gelesen haben sollte ist "The 
Art of UNIX Programming". Das Buch gibts selbstverständlich auch vom 
Autor online. Das stellt im Prinzip vor, wie denn Wiederverwendung unter 
UNIX gemacht wird.

7856ujtzuitzu schrieb:
> wenn man die google suche bemüht resultiert ein link zu einer PDF die
> witzigerweise das buch enthält

Und Frank Liu wird vermutlich jede Menge Ärger bekommen.

W.S. schrieb:
> Mich hatte schon vor Ewigkeiten sowas wie sprintf und Konsorten
> geärgert.

Als erfahrener Programmierer sollte man aber auch alte Vorurteile 
revidieren können, denn nichts ist in Stein gemeißelt.
Die Zeit ist ja seit 1980 beim 8051 mit 4kB PROM und 128Byte RAM nicht 
stehen geblieben.
Z.B. ein im gleichen DIP-40 Gehäuse sitzender ATmega1284 hat 128kB Flash 
und 16kB RAM.
Ich habe früher auch mal printf/scanf und float gemieden, aber 
heutzutage muß man das nicht mehr.
Auch sind die C-Compiler deutlich besser geworden und lehren so manchen 
Assembler-Fan das Fürchten.

Peter D. schrieb:
> Auch sind die C-Compiler deutlich besser geworden und lehren so manchen
> Assembler-Fan das Fürchten.

Wie kommst Du darauf, das sich Assewmbler Fans für C überhaupt 
interessieren?
Einem eingefleichten Kite-Surfer ist es Wurst (sorry, Herr Conchita!), 
ob die Rennräder immer besser werden.
Das sind zwei verschiedene Dinge, die überhaupt nicht vergleichbar sind. 
Das bringt jemand weder zum Lächeln, noch zum Fürchten.

Route 6. schrieb:
> Wie kommst Du darauf, das sich Assewmbler Fans für C überhaupt
> interessieren?

Das nicht, aber sie merken, daß sich damit kein Geld mehr verdienen 
läßt.
Assembler ist nur noch in der Hobby-Nische vorhanden.

Noch einer schrieb:
>> Ich fand's 'nen sehr interessanten Ansatz
>
> Das Problem bei den interessanten Ansätzen ist leider - es gibt so viele
> interessante Ansätze, die nicht zusammen passen.
>
> Gerade weil eine Komponente einen genialen Ansatz hat, der nicht mit dem
> langweiligen Rest zusammen arbeitet, kann man sie nicht wieder
> verwenden.

Dafür gibt es das Adapter Pattern bzw. Wrapper. ;-)

xXx schrieb:
> Und genauso wie die Assembler-Fans ihren verlorenen Posten gegenueber C
> verteidigt haben, tun es nun die C-Fans gegenueber C++ - nur mit noch
> schlechteren Argumenten.

Sieht das hier für Dich nach verlorenem Posten aus?

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Jay schrieb:
> s ist eher umgekehrt. Die C++-Fans machen lautstark Rabatz weil die
> Zukunft wie sie sie gerne hätten einfach nicht kommen möchte. Es gibt
> ganz objektive Gründe warum sie nicht kommt, aber das lohnt sich nicht
> hier auszubreiten.

Es scheint noch nicht überall bekannt zu sein, daß C++ bereits verwendet 
wird.

Karl H. schrieb:
> Und abgesehen davon, würde ich aus dem Hause "Addison-Wesley
> Professional Computing" so ziemlich alles auch unbesehen kaufen.

Möchte ich mal unterstreichen. Alle Bücher von denen waren 
ausgesprochen gut.

Falk S. schrieb:
> Ich kenn obiges Buch leider nicht, kann Dir aber das "Test-Driven
> Development for Embedded C" von J. Grenning nahe legen. Legt sehr viel
> Wert auf CleanCode und Interface-Driven-Development. Als Interfaces
> werden dabei Funktionspointertypen verwendet - die implementierten
> Funktionen, die diesem Typ entsprechen, werden dann austauschbar gemäß
> dem Strategiemuster. Ich fand's 'nen sehr interessanten Ansatz - ist
> aber letztlich das, was C++ unter der Haube bei den VTables auch macht.
> Wer aber auf reine ANSI-C-Entwicklung angewiesen ist und versuchen
> möchte, Design-Patterns prozedural anzuwenden um SOLIDen Code zu
> produzieren, dem sei das TDD-Buch durchaus zu empfehlen:

[Link mit Copyright-Verstoß gelöscht]

Vortrag dazu:
http://www.odd-e.com/material/2012/08_tdd_in_c/tddec.pdf

Übrigens sehr interessanter Thread!

> Sieht das hier für Dich nach verlorenem Posten aus?
>
> http://www.tiobe.com/index.php/content/paperinfo/t...

Bei Statistiken muß man halt immer schauen, wo die Daten herkommen.
In diesem Fall werden Sprachen hoch ge-rated, die bei u.A. bei Google 
und Youtube häufig erwähnt werden.
Man könnte mit gleicher Sicherheit auch sagen, das sind die, die die 
meisten Probleme machen. Genau so gut könnten das die beliebtesten 
Sprachen sein. Betonung liegt jeweils auf könnte.
Seriöse Statistiken würden die Anzahl Stellenausschreibungen, Projekte, 
oder auch LineOfCode verwenden. Denn das zu wissen, damit werben die 
groß.
So hat man eher den Verdacht, daß es hauptsächlich um "Werbe-Clicks" 
geht.

OldMan schrieb:
> Dass dieser Beitrag noch nicht gelöscht ist verwundert mich.

Jetzt issers.

Querleser schrieb:
> Habe das Buch gerade mal quergeblättert. Der Titel ist irreführend,
> meiner Meinung nach.
>
> Das Buch ist quasi eine gedruckte Form einer Utility-Bibliothek, mit
> Dingen wie Listen, Sets, String-Funktionen, Threads und noch einige
> anderen, auch etwas ungewöhnlicheren Dingen.

Ich habe das Buch auch mal überflogen und komme zu einem ähnlichen
Ergebnis:

Die 24 behandelten Interfaces sind wohl eher als Beispiele für die
Umsetzung zu sehen. Was allerdings viel zu kurz kommt, ist eine
Erläuterung, warum die Interfaces in der beschriebenen Form "gut" sind
und wie im Vergleich dazu "schlechte" Interfaces aussehen würden.
Stattdessen wird der Schwerpunkt auf die jeweilige Implementation
gelegt.

Da anfangs auch von abstrakten Datentypen die Rede ist (die ja in engem
Zusammenhang mit Interfaces stehen), hätte ich eigentlich ein paar
Vorgehensweisen zu deren Einsatz in der generischen Programmierung
erwartet, was auch den Bogen zu der im Vorwort erwähnten
Wiederverwendung von Softwaremodulen geschlossen hätte.

Andererseits muss man sagen, dass die behandelten Softwaremodule
größtenteils sehr elegant implementiert sind, so dass sie zumindest
implementierungstechnisch ein gutes Beispiel für den angehenden
C-Programmierer darstellen. Insofern ist das Buch nicht für die Katz,
wenn es nur einen anderen Titel hätte. Mit dem aktuellen Titel wird es
aber vermutlich von den falschen Leuten gekauft.

W.S. schrieb:
> btw: was soll eigentlich der bellende Unsinn, für eine ZEICHEN -
> Ausgabe einen uint8_t zu nehmen??? Dort gehört ein simpler char hinein,

Ich habe mir ebenfalls angewöhnt, mit uint8_t als Basis bei der Daten 
De/Serialisierung zu arbeiten.

Hat da jemand tatsächlich schon Mal 'ne Weiche im Code gebaut für !=8 
Bit char?! Mag ich gar nicht dran denken.

Der Typ char ist imho auch "verwirrend". Mir fällt auf aktuellen 
Systemen keine vernünftige Anwendung ein. Vielleicht weiß hier jemand 
wie char -- zusätzlich zu signed/unsigned char -- entstanden ist.

Was ist daran verwirrrend?
char ist genau dafür da: ein Zeichen zu speichern und ggf. auf ==0 oder 
!=0 zu testen.

Da interessiert mich das Vorzeichen nicht.

Nimmt jemand dafür int8_t oder uint8_t, fragt sich der geneigte Leser 
wieso mit diesem Typ gerechnet werden soll (nur dann wäre signed oder 
unsigned überhaupt sinnvoll).

Schreibt man char, drückt man klar aus, worum es geht: Zeichen.

S. J. schrieb:
> W.S. schrieb:
>> btw: was soll eigentlich der bellende Unsinn, für eine ZEICHEN -
>> Ausgabe einen uint8_t zu nehmen??? Dort gehört ein simpler char hinein,
>
> Ich habe mir ebenfalls angewöhnt, mit uint8_t als Basis bei der Daten
> De/Serialisierung zu arbeiten.

Für Binärdaten ist das auch ok, aber nicht für Text.
Bei putchar steht das char ja schon im Namen. Da kommt es etwas 
überraschend, daß dann statt eines char ein uint8_t ge"puttet" wird. 
Warum heißt die Funktion dann nicht putuint8_t?

> Der Typ char ist imho auch "verwirrend". Mir fällt auf aktuellen
> Systemen keine vernünftige Anwendung ein. Vielleicht weiß hier jemand
> wie char -- zusätzlich zu signed/unsigned char -- entstanden ist.

Das wurde in letzter Zeit öfters hier im Forum durchgekaut:

Wenn du Text brauchst, nimm char.
Wenn du einen möglichst kleinen Integer brauchst, nimm [un]signed char.
Wenn du einen Integer brauchst, der zwingend exakt 8 Bit breit sein muß, 
nimm uint8_t.
Wenn du einen möglichst effizient zu verarbeitenden Integer brauchst, 
der mindestens 8 Bit breit ist, nimm uint_fast8_t.
Wenn du einen möglichst kleinen Integer mit mindestens 8 Bit brauchst, 
nimm uint_least8_t. (Bringt bei 8 Bit noch nicht so viel. Die 
*_least*-Typen werden erst bei meht als 8 Bit wirklich interessant.)

Klaus W. schrieb:
> char ist genau dafür da: ein Zeichen zu speichern und ggf. auf ==0 oder
> !=0 zu testen.
>
> Da interessiert mich das Vorzeichen nicht.

Ja, das sorgt regelmäßig für Spaß bei den Programmierern.
Warum funktioniert denn das verdammte Mapping der Umlaute von ASCII nach 
LCD nicht?
Bis man endlich dahinter kommt, daß Umlaute negativ sind.
Oder man hat im String mehrbytige Zahlen, die jedes Byte sign extended 
nur Mumpitz ergeben.

Also immer bei Rechnungen und Vergleichen mit Strings erstmal alles nach 
uint8_t casten.
Hätte man wirklich besser machen sollen.

Rolf M. schrieb:
> Für Binärdaten ist das auch ok, aber nicht für Text.

Gerade für "Text" wäre die Definition als unsigned char völlig 
ausreichend gewesen.

Weil's mich interessiert, habe ich es mal hier weitergeführt:

Beitrag "C Language: char vs. signed char vs. unsigned char"

chris_ schrieb:
> Deshalb hege ich eine inherente Abneigung gegen "unscharfe"
> Datentypen ( übrigens auch gegen Besserwisser ).

Ich wäre auch eher dafür gewesen, char fix als signed festzulegen, da es 
letztendlich auch nur genau so ein Integer-Typ ist, wie die anderen. Und 
bei allen Integertypen ist eindeutig definiert, daß sie ohne explizite 
Angabe signed sind, außer eben bei char. Damit ist das nicht konsistent 
umgesetzt.
Deine Abneigung sollte sich übrigens auch gegen Programmierer richtgen, 
die mit den Datentypen nicht richtig umgehen können. Und nein, das hat 
nichts mit Besserwisserei zu tun. Es ist nur so, daß wenn jemand ein 
Werkzeug nicht richtig benutzt, das nicht immer die Schuld des Werkzeugs 
ist.

S. J. schrieb:
> Rolf M. schrieb:
>> Für Binärdaten ist das auch ok, aber nicht für Text.
>
> Gerade für "Text" wäre die Definition als unsigned char völlig
> ausreichend gewesen.

Gerade für Text ist es aber eigentlich auch egal.

Peter D. schrieb:
> Klaus W. schrieb:
>> char ist genau dafür da: ein Zeichen zu speichern und ggf. auf ==0 oder
>> !=0 zu testen.
>>
>> Da interessiert mich das Vorzeichen nicht.
>
> Ja, das sorgt regelmäßig für Spaß bei den Programmierern.
> Warum funktioniert denn das verdammte Mapping der Umlaute von ASCII nach
> LCD nicht?

Da wurde die nötige Konvertierung vom Text-Typ in den Registerwert 
vergessen.

> Also immer bei Rechnungen und Vergleichen mit Strings erstmal alles nach
> uint8_t casten.

Warum sollte man bei Vergleichen irgendwas casten müssen?
Und die Rechnungen braucht man nur an der einen Schnittstelle zwischen 
der eigentlichen Funktionalität des Programms und der Lowlevel-I/O. Von 
"immer" würde ich da nicht sprechen, denn das sollte eigentlich nur pro 
Hardware-Einheit, an die Text ausgegeben werden soll, genau an einer 
Stelle passieren.

> Hätte man wirklich besser machen sollen.

Ja. Man hätte komplett getrennte Typen für Text und Integer definieren 
sollen, genau so, wie z.B. in Pascal: char nur für Text und ohne 
irgendwelche signed/unsigned-Varianten und ohne direkten Zugriff auf den 
internen Zahlenwert. Und dann einen Typ byte, den's mit oder ohne 
Vorzeichen gibt. Zur Konvertierung zwischen Text und Integer dann pro 
Richtung eine Funktion.
In C kann (und sollte) man es eigentlich auch entsprechend diesem 
Prinzip machen, aber das erfordert eben etwas mehr Disziplin, da die 
Sprache es nicht erzwingt.