Dateitypen uint8_t, uint16_t, ...
-
Hallo,
ich schreibe gerade eine Bibliothek und bin mir nicht ganz sicher was für
Datentypen ich für Integer verwenden soll. Viele Bibliotheken definieren ihre
eigenen Datentypen oder verwenden unsigned int auch, wenn es viel zu groß
für die Daten ist.Ich habe mich jetzt dafür entschieden uint8_t, uint16_t, ... zu
verwenden und den kleinst möglichen Datentyp zu verwenden. Allerdings kenne ich
nicht viele C-Programme welche diese Datentypen benutzen. Kann ich das so machen? Ist das guter Stil?Gruß
Hans Baumer
-
Kannst machen. Musst du wirklich Speicher sparen? Meistens ist es von der Geschwindigkeit her günstig, einfach die Standarddatentypen (int, unsigned int) zu nehmen.
Das wird übrigens so selten benutzt, da diese typedefs erst mit C99 eingeführt wurden. Ein großer, bekannter Compiler (Microsoft) kann jedoch nur C89 und das wird sich auch nicht mehr ändern.
-
MSVC unterstützt <stdint.h> meines Wissens seit der 2010er Version.
Ansonsten ist es schwer, diese Frage allgemeingültig zu beantworten - für Netzwerkcode gelten andere Regeln als für Embedded-Code und ganz andere als für GUI-Bibliotheken. Kannst du vielleicht kurz umreißen, was deine Bibliothek machen soll?
-
Hallo,
danke für die schnellen Antworten. Es geht um eine Bibliothek zum entpacken von
einem bestimmten Archiv. Das Einsatzgebiet ist eher nicht im Embedded-Bereich
aber trotzdem würde ich gern so sparsam wie möglich mit dem Speicher umgehen.Warum normale Integer besser sind kann ich nicht ganz verstehen, weil durch jeden
Speicherzugriff ja gleich ganze Cache-Lines in den Cache geladen werden und durch
kleinere Variablen (z.B uint8_t statt unsigned int) mehr Variablen in den Cache passen.Gruß
Hans Baumer
-
Denk mal nach, wie ein int8_t auf einem 64-Bit Computer wohl bearbeitet wird.
-
SeppJ schrieb:
Denk mal nach, wie ein int8_t auf einem 64-Bit Computer wohl bearbeitet wird.
Hallo,
ich verstehe dein Einwand nicht. Klar wird das 8-Bit Datenwort wie ein 64-Bit Datenwort bearbeitet aber das 8-Bit Datenwort wird als ein Byte gespeichert und nicht mit vier Byte oder? Welchen Nachteil siehst du da jetzt genau?Gruß
Hans
-
hans.b schrieb:
ich verstehe dein Einwand nicht. Klar wird das 8-Bit Datenwort wie ein 64-Bit Datenwort bearbeitet aber das 8-Bit Datenwort wird als ein Byte gespeichert und nicht mit vier Byte oder?
Genau. Das bedeutet aber für den Verarbeitungsschritt, dass zuerst das 64-Bit Wort geladen werden muss, das unser byte beinhaltet, dann muss da irgendwie das Byte rausgeholt werden (Bitmaske oder so), dann verarbeitet und dann wieder in das 64-Bit Wort reingestopft werden, ohne den Rest des Wortes zu verändern.
Ja, das kann schneller sein, wenn die anderen Teile des Gesamtwortes auch noch gebraucht werden (und zwar möglichst oft). Es wird aber langsamer sein, wenn dies nicht der Fall ist. Für irgendwelche Allerweltsvariablen würde ich daher einfach int oder ähnliches nehmen. Erst bei Daten die wirklich stark benutzt werden, würde ich eher aufpassen.
Typisches Beispiel, das sehr oft hier im Forum kommt: Sieb des Erastothenes. Als schnellste Umsetzung hat sich bis jetzt die erwiesen, bei der man die Bitwerte wirklich Bitweise in einem größeren Datenwort codiert (also umstandlicher Zugriff), da man wirklich sehr, sehr viele Zugriffe hat. Gleichzeitig ist es bei dieser Umsetzung aber auch günstiger, vor einer Zuweisung noch eine (eigentlich teure) Abfrage zu machen, ob die Variable schon den richtigen Wert hat, eben weil jeder unnötige Zugriff so teuer ist.
-
hans.b schrieb:
...aber das 8-Bit Datenwort wird als ein Byte gespeichert und nicht mit vier Byte oder? Welchen Nachteil siehst du da jetzt genau?
Gruß
HansNein.
Das Stichwort lautet Alignment
-
Die Ausrichtung eines Datentyps ist nie größer als seine Größe, sonst wär das mit Arrays schwierig. uint8_t ist ein Byte groß, daher wird er auch auf ein Byte ausgerichtet.
Ansonsten dürfte die genaue Breite des verwendeten Datentypen im Zusammenhang mit Kompression häufig von Bedeutung sein. Für Schleifenvariablen und so muss das jetzt nicht unbedingt sein, aber bei den Daten selbst ergibt das anders wenig Sinn.