Im Moment beschäftige ich mich damit, wiederverwendbare Software-Module zu schreiben. Dazu habe ich ein Buch gefunden: http://www.amazon.de/Interfaces-Implementations-Techniques-Addison-Wesley-Professional/dp/0201498413 Es scheint schon ein wenig älter, kennt es jemand?
:
Verschoben durch Admin
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.
:
Bearbeitet durch User
Das Buch klingt sehr interessant. In welchen Applikationen kommt den wiederverwendbare Software vor? I/O-Module?
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. Ja, die einzelnen Funktionen sind ausführlich beschrieben etc. Aber es geht in diesem Buch genau nicht darum, wie man ein gutes Interface schreibt etc. Es wird nur Source-Code besprochen. 50 Kröten dafür? Never. Suchmaschine und trojanerresistenten Browser auf einem virenfesten Betriebssystem bemühen...
Und damit sind wir mitten in einem ganz düsteren Thema. Da finde ich 3 Module mit hervorragendem Interface, die genau das machen, was ich brauche. Ließe sich für das aktuelle Projekt wiederverwenden, aber alle 3 Module benutzen unterschiedliche Ansätze für Listen, Sets und String-Funktionen. Hätte sich damals nur eines dieser Bücher durchgesetzt...
Marcus schrieb: > Im Moment beschäftige ich mich damit, wiederverwendbare Software-Module > zu schreiben. Das ist brotlose Kunst. Laß es lieber und programmiere was vernünftiges. Mich erinnert das an das, was man seit Jahren auf der Embedded sehen kann: 99 Ingenieurbüros, die irgendwelche wiederverwendbare Hardware-Module anbieten und nach Anwendungen suchen. Habe Lösung, suche Anwendung für meine Lösung. So herum wird das nix. Meine Erfahrung ist, daß sich wiederverwendbares Zeugs von selbst ergibt, wenn man ein konkretes Projekt sinnvoll modularisiert. Letzteres (das sinnvolle Modularisieren) ist viel wichtiger als der Vorsatz, Wiederverwendbare Module schreiben zu wollen ohne selbige selbst im konkreten Projekt zuvor eingesetzt zu haben. W.S.
> wenn man ein konkretes Projekt sinnvoll modularisiert.
Gibt es Bücher, aus denen man so etwas lernen kann? Oder geht das nur
aus Erfahrung?
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.
:
Bearbeitet durch User
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.
> 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.
Noch einer schrieb: > Gibt es Bücher, aus denen man so etwas lernen kann? Oder geht das nur > aus Erfahrung? Bücher? Hör mal: Erfahrung ist keine Handelsware. Man muß sie selber machen. Ein jeder für sich. Aber es hilft vielleicht, wenn man mal aus dem Nähkästchen plaudert und wenn einem dabei zugehört wird. Ein Beispiel: Mich hatte schon vor Ewigkeiten sowas wie sprintf und Konsorten geärgert. Warum? weil man einerseits völlig unnütze Formatstrings in den knappen Speicher von µC einbauen mußte (und weil C im Gegensatz zu Pascal keinerlei Literalsharing kennt) und andererseits einen fetten Textinterpreter noch dazu, der diese Formatstrings auswertet. Obendrein mußte das Ergebnis ja erstmal in einen RAM-Bereich hinein, entweder auf den knappen Stack oder noch schlimmer in statische RAM-Arrays - oder (noch viel schlimmer) in per malloc und so akquirierten RAM. Kurzum, das übliche C-Verfahren ist auf µC einfach nur gequirlte Sch***, weil es in diese Sprache eben keine Auflösung komplexerer Funktionen zur Compilierzeit gibt (Gegensatz: write bei Pascal). Also schrieb ich mir vor wirklich langer Zeit einen Unit "conv.c", der die wichtigsten Konvertierungen enthält und den ich zusammen mit sowas wie String_Out(String, wohin) verwenden konnte, OHNE Formatstrings und Interpreter in die Firmware hineinlinken zu müssen. Zu Zeiten, wo 64K Flash die Obergrenze war, war das äußerst hilfreich. Tja, dieses Stück Quellcode hat überlebt, hat diverseste µC Generationen gesehen - 8 und 16 und 32 Bit, BigEndian und LittleEndian, ist währenddessen auch mächtiger geworden (int64 usw) und ich benutze es immer noch. Eas war nie geplant, sowas als "wiederverwertbaren Softwaremodul" u schreiben, sondern es hat sich eben so ergeben. So herum läuft es. Ein ähnliches Stück Software sind meine Fonts und mein GDI, was mittlerweile in Color-Version und B/W-Version und (Lernbetty) in 4 Stufen Grau-Version auf untershiedlichsten Systemen und mit unterschiedlichsten Displays läuft. Das war auch nie als Universal-GDI geplant, aber wenn man die Fundamente sinnvoll gelegt hat, kommt sowas fast wie von selbst. Ein putziges Beispiel am Rande: manchmal findet man den gleichen Peripherie-Core in Konkurrenzprodukten: Als ich meinen SDIO-Treiber für die LPC24xx fertig hatte und selbiges auch für die STM32F1xx anfing, fiel mir auf, daß die Cores fast gleich sind und der einzige Unterschied die Adressen und die Bezeichnungen sind (MCI_xxx versus SDIO_xxx). So paßte der NXP-Treiber nach Adreß- und Namenskorrektur perfekt auch auf die STM32 drauf. Bei anderen, eher hardwarenahen Teilen zählt die Erfahrung: Wer einen gepufferten per Interrupt organisierten UART-Treiber für einen Prozessor mal geschrieben hat, der kann das in 99% aller Fälle auch für andere Prozessoren in gleicher Weise tun. Die Namen der Interrupt-Handler mögen sich unterscheiden, aber die Herangehensweise ist gleich. Genau dasselbe gilt auch für sowas wie das hinlänglich hier diskutierte Entprellen von Tasten. W.S.
W.S. schrob: >Bücher? >Hör mal: Erfahrung ist keine Handelsware. Man muß sie selber machen. >Ein jeder für sich. Erfahrung ist der Weisheit bitterster Weg.
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. Ja, die einzelnen > Funktionen sind ausführlich beschrieben etc. Aber es geht in diesem Buch > genau nicht darum, wie man ein gutes Interface schreibt etc. Es wird nur > Source-Code besprochen. > > 50 Kröten dafür? Never. Suchmaschine und trojanerresistenten Browser auf > einem virenfesten Betriebssystem bemühen... also ich war erschrocken ... dieser ratschlag zieht mal wirklich wenn man die google suche bemüht resultiert ein link zu einer PDF die witzigerweise das buch enthält gleich darunter ein github link mit scheinbar allen sourcen und das nur weil man sucht und mal wissen will ob das buch jemand kennt
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.
:
Bearbeitet durch User
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.
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.
Falls du mit "verlorenen Posten" den verloren gegangen bezahlten Arbeitsplätze meinst. Erstaunlicherweise lässt sich aus keiner der widersprüchlichen Statisten ableiten, C würde von C++ verdrängt. Sieht eher so aus, als würden neue Sprachen wie C# oder Ruby die alten verdrängen.
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
:
Bearbeitet durch User
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. Es 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.
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.
Klaus W. schrieb: > 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. Kommt Zeit, kommt C++.
Wie wäre es mit ein wenig Praxis? Bei MCs verwende ich immer folgendes Verfahren für meine "wiederverwendbaren" Module: Ich mache mir eine Schnittstellenbeschreibung als "system_io.h" file. In dieser Datei stehen dann die Schnittstellen
1 | void SYSTEM_putchar(uint8_t c); |
2 | uint8_t SYSTEM_getchar(void); |
3 | void SYSTEM_printText(uint8_t * str); |
4 | void SYSTEM_waitms(uint32_t time_ms); |
5 | ..
|
Die Runtime-Umgebung muss dann diese "Requested Interfaces" zur Verfügung stellen. Üblicherweise ist das bei mir eine Simulationsumgebung auf dem PC um die Routinen schnell zu testen und dann mehrere Microcontroller Derivate.
Peter D. schrieb: > Als erfahrener Programmierer sollte man aber auch alte Vorurteile > revidieren können, denn nichts ist in Stein gemeißelt. Als noch erfahrenerer Programmierer hat man Urteile und keine Vorurteile. Mal im Klartext: Manche Dinge passen in eine bestimmte Umgebung und sind deplaziert in einer anderen Umgebung. Und hier ging es um ein Stück Beispielquelle, das sich zumindest bei mir bewährt hat. Aber das ist mein Bier und andere halten es anders: chris_ schrieb: > In dieser Datei stehen dann die Schnittstellen > void SYSTEM_putchar(uint8_t c); > uint8_t SYSTEM_getchar(void); > void SYSTEM_printText(uint8_t * str); > void SYSTEM_waitms(uint32_t time_ms); Siehst du, so macht sich ein jeder sein Zeugs zurecht und sammelt seine Erfahrungen selbst. Ob ich den stil von Chris mögen würde, ist was anderes, ich hätte an seiner Stelle mir nen Unit gemacht, der sowas wie ne E/A-Weiche ist. Damit braucht man im Hauptteil der Firmware nichts mehr zu ändern, wenn man E/A-Ströme auf verschiedene Kanäle lenken will. Also z.B. SYSTEM_PutChar(char c, int DeviceID); btw: was soll eigentlich der bellende Unsinn, für eine ZEICHEN - Ausgabe einen uint8_t zu nehmen??? Dort gehört ein simpler char hinein, es sei denn man braucht 16 Bit Unicode, wo dann ein TCHAR oder so ähnlich hingehören würde. Die jungen Leute denken einfach nicht mehr nach oder haben vor lauter Umdefiniererei den Boden unter den Füßen verloren. W.S.
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!
:
Bearbeitet durch Moderator
Tcf K. schrieb: > Ist auch als PDF "verfügbar": > [Link mit Copyright-Verstoß gelöscht] Dass dieser Beitrag noch nicht gelöscht ist verwundert mich. Als ich mal einen Link auf eine Universitätsseite mit einem freien PDF-Dokument angegeben habe, wurde der gleich wie gelöscht. Tja, so sind sie eben die lieben Menschen. Keine festen Regeln!
:
Bearbeitet durch Moderator
> 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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.)
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, >es sei denn man braucht 16 Bit Unicode, wo dann ein TCHAR oder so >ähnlich hingehören würde. Die jungen Leute denken einfach nicht mehr >nach oder haben vor lauter Umdefiniererei den Boden unter den Füßen >verloren. Tja, wie war das noch mal gleich mit der Erfahrung? Der eine hat sie, der andere nicht. Üblicherweise ist der Typ "char" als "sint8_t" definiert. Manche Compiler bieten allerdings die Option "char" als "int8_t" umzudefinieren. Da das in einem der Projekte an denen ich mitgeabeitet habe, der Fall war, gab es lange Suchaktionen der ganzen Manschaft nach einem Fehler der durch ein Stück Code von einem der Programmierer entstand. Deshalb hege ich eine inherente Abneigung gegen "unscharfe" Datentypen ( übrigens auch gegen Besserwisser ).
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.