Unterschied zw. uint8_t und unsigned int

http://en.wikipedia.org/wiki/Stdint.h

> ein "unsigned integer" hat auf x86
> vier Bytes, also 32 Bits.

Sofern x86 = 386 und aufwärts im 32-Bit-Modus.

Bei üblichen 8-Bit-Systemen wie AVR, MSP430 etc. ist ein unsigned 
integer 16 Bit groß, bei x86 im 16-Bit-Modus ("real mode") auch.

Nein, wie gross ein Integer ist hängt von dem System ab auf dem es 
laufen soll.


Gruß

Tom wrote:
> Ja, aber warum ist ein unsigned int 2 bzw. 4 Byte groß? Es handelt sich
> doch hier um einen 8 Bit, also 1 Byte Datentyp? Versteh ich nicht ganz.

Nein, ein "int" egal ob signed oder nicht, bezeichnet zunächst nur den 
Datentyp und nicht die Bitbreite. Tatsächlich handelt es bei "int" nur 
in den seltensten Fällen um 8Bit. Für sowas ist in der Regel der 
Datentyp "char" zuständig. Aber auch hier ist die Bitbreite 
hauptsächlich vom System und Plattform abhängig.

Nur "uint8_t" ist hier explizit, gehört damit aber wohl nicht zum 
Standard, da C ursprünglich als Programmiersprache vorallem portabilität 
bringen sollte. Unter diesen Gesichtspunkten spielt die Bitbreite eines 
Datentyps eine nur untergeortnete Rolle.

hans wrote:
> Das bedeutet, daß ein Mega 8 mit "natürlicher" Breite von 8 Bit
> (daher auch MEGA 8 ;)) ein Integer von 8 Bit hat.
> (Mega 16 dann 16 Bit Integer)
>
> Nur seltsam beim Tiny 13 !

Richtig interessant wird so eine Betrachtung erst beim ATtiny861!


lol?

Diese uint8_t oder auch int8_t, etc. sind selbstdefinierte Typen aus der 
AVRlib. Erspart geringfügig Tipparbeit. Ein uint8_t ist schlicht ein 
unsigned char, ein int8_t ist ein char. Mehr nicht. Achja, ein 'int' 
(integer) ist auf dem AVR 16bit breit. Ich habe es mir mittlerweile 
angewöhnt, die bei C üblichen Typen-Bezeichner zu verwenden. Da braucht 
man sich dann nicht umzugewöhnen.

Gruß
Jadeclaw.

Jadeclaw Dinosaur wrote:
> Diese uint8_t oder auch int8_t, etc. sind selbstdefinierte Typen aus der
> AVRlib.
Neee, sind es nicht. Die gehören zur GCC Standardlibrary. 
Beziehungsweise sogar zum C-Standard.

> Erspart geringfügig Tipparbeit. Ein uint8_t ist schlicht ein
> unsigned char, ein int8_t ist ein char. Mehr nicht. Achja, ein 'int'
> (integer) ist auf dem AVR 16bit breit.
Es erspart nicht (nur) Tipparbeit. Hauptsächlich soll man damit die 
Programme weitgehend portabel halten. Ein großer Vorteil ist aber auch, 
dass man der Variable den Wertebereich sofort ansieht, ohne großartig 
suchen zu müssen, wie dieser wäre.

Jadeclaw Dinosaur wrote:
> Diese uint8_t oder auch int8_t, etc. sind selbstdefinierte Typen aus der
> AVRlib. Erspart geringfügig Tipparbeit. Ein uint8_t ist schlicht ein
> unsigned char, ein int8_t ist ein char. Mehr nicht. Achja, ein 'int'
> (integer) ist auf dem AVR 16bit breit.

Da hast du natürlich recht. In der uC-Welt spielt es ohnehin keine 
Rolle, ob man sich an Standards hält oder nicht, da der Code meist sehr 
Hardware- bzw Plattformabhängig ist.

Wer allerdings portabel bleiben will, bzw die Anpassung auf andere 
mögliche Hardware vereinfachen will, sollte bei den "selbstdefinierten" 
Datentypen zurückgreifen, wenn eine Variable bitbreitenabhängig wird.

Simon K. wrote:
.
> Neee, sind es nicht. Die gehören zur GCC Standardlibrary.
> Beziehungsweise sogar zum C-Standard.

hust sorry, aber das stimmt ganz gewiss nicht!
Standarddatentypen im Ganzzahlenbereich sind char, short, int und long. 
Mehr nicht! Ihre Bitbreiten sind zur Compile-Zeit festgelegt und laut 
Ansi- standard in der limits.h festgelegt bzw abrufbar.

Bezeichner wie "uint8_t" haben sich lediglich als Beiwerk zum Standard 
durchgesetzt.

Niels Hüsken wrote:
> Simon K. wrote:
> .
>> Neee, sind es nicht. Die gehören zur GCC Standardlibrary.
>> Beziehungsweise sogar zum C-Standard.
>
> hust sorry, aber das stimmt ganz gewiss nicht!
> Standarddatentypen im Ganzzahlenbereich sind char, short, int und long.
> Mehr nicht! Ihre Bitbreiten sind zur Compile-Zeit festgelegt und laut
> Ansi- standard in der limits.h festgelegt bzw abrufbar.
>
> Bezeichner wie "uint8_t" haben sich lediglich als Beiwerk zum Standard
> durchgesetzt.

Was stimmt nicht?

stdint.h is a header file in the C standard library introduced in the 
C99 standard library section 7.18 to allow programmers to write more 
portable code by providing a set of typedefs that specify exact-width 
integer types, together with the defined minimum and maximum allowable 
values for each type, using macros.

http://en.wikipedia.org/wiki/Stdint.h

crazy horse wrote:
> mal eine Frage zur Portabilität: hat das wirklich schon mal einer
> gemacht? Also ein Programm, z.B. für den 8051, auf AVR oder M16 laufen
> lassen? Also ich noch nicht :-)

Das hängt natürlich vom Bedarf ab, da hierfür ein mehr oder 
minder-erheblicher Aufwand betrieben werden muss. Aber ich halte es auf 
keinen Fall für undenkbar, daß man hardwarespezifische Programmteile in 
austauschbare Header packt um damit eine mögliche Portierung zu 
vereinfachen.

Der C99-Standard wurde nachträglich zum bestehenden ISO-Standard 
adaptiert. In meinen Augen ist der Grauzone, da längst nicht alle 
Compiler diesen Standard implementieren.

Zugegeben, beim GCC scheint man jedoch auf der sicheren Seite zu sein, 
was die implementierung der so genannten exact-width-integer Typen 
betrifft.

let wrote:
> Und natürlich gehört uint8_t zum C-Standard. Das sich nicht alle
> Compiler daran halten (und auch nach neun Jahren bestenfalls C89
> unterstützen) ist eine andere Geschichte.

Ich bleibe dabei: der C99-Standard ist ein Beiwerk, der in seinem vollen 
Umfang nicht mal vom GCC unterstützt wird. Das sagt auch der 
Wiki-Artikel:

"GCC, despite its extensive C99 support, is still not a completely 
compliant implementation; some features are missing or do not work 
correctly."

> Ich bleibe dabei: der C99-Standard ist ein Beiwerk, der in seinem vollen
> Umfang nicht mal vom GCC unterstützt wird.

Es ist der Standard im Sinne von "Norm". Allerdings implementieren nur 
sehr wenige Compiler diesen Standard, die meisten halten sich noch an 
C89 ("ANSI-C").

crazy horse wrote:
> tja, dann  muss man aber von Anfang an genau drauf achten. Meine Frage
> war ja auch nicht, ob es geht (ja, dass geht), sondern ob es schon mal
> jemand gebraucht/gemacht hat?

Ja, teilweise.  Man braucht das ziemlich schnell (bzw. es wird mit
den <stdint.h>-Typen nun endlich genormt), wenn man bestimmte Software
beispielsweise auf AVR und ARM (oder AVR32) einsetzen will.  Da ist
dann auch noch ein wenig mehr Nachdenken angesagt: uint8_t ist dort
keineswegs überall sinnvoll, sondern in der Regel wird man besser
einen uint_fast8_t benutzen, d. h. der am schnellsten zu verarbeitende
Datentyp, der mindestens 8 bits breit ist.  uint8_t dagegen ist dann
angebracht, wenn darin beispielsweise Daten eines externen Protokolls
unterzubringen sind.  Falls das dann irgendjemand mal vorhaben sollte
auf einen TI 32-bit-DSP zu portieren, wird ihm der Compiler sofort
mitteilen, dass das nicht geht.  Hätte der Programmierer statt uint8_t
dagegen "unsigned char" benutzt, wäre er stillschweigend auf die Nase
gefallen, obwohl sich alles compilieren lässt...  (Wer's nicht kennt:
diese DSPs kennen keine 8-bit-Datentypen, sondern nur 32-bittige.
Damit ist auch ein "unsigned char" 32 bit breit.)

crazy horse schrob:
> tja, dann  muss man aber von Anfang an genau drauf achten. Meine Frage
> war ja auch nicht, ob es geht (ja, dass geht), sondern ob es schon mal
> jemand gebraucht/gemacht hat?

Ja, allerdings "nur" um Grafik-Routinen, die für AVR gedacht waren, auf 
einem PC zu testen. Dabei ging es nicht um ein komplettes Programm, 
sondern nur um die fraglichen Module. Mit ein paar Makros hat man die 
Hardwareabhängigkeit rausparametriesiert (falls man im Ansatz schon 
drauf geachtet hat)

Beitrag "Vektor-Font in C"

Johann L. wrote:
> crazy horse schrob:
>> tja, dann  muss man aber von Anfang an genau drauf achten. Meine Frage
>> war ja auch nicht, ob es geht (ja, dass geht), sondern ob es schon mal
>> jemand gebraucht/gemacht hat?
>
> Ja, allerdings "nur" um Grafik-Routinen, die für AVR gedacht waren, auf
> einem PC zu testen. Dabei ging es nicht um ein komplettes Programm,
> sondern nur um die fraglichen Module. Mit ein paar Makros hat man die
> Hardwareabhängigkeit rausparametriesiert (falls man im Ansatz schon
> drauf geachtet hat)
>
> Beitrag "Vektor-Font in C"

Was vergleichbares habe ich auch mal gemacht für mein uFS-Filesystem 
damals. Da konnte ich die Header/Sources auf dem PC schreiben/debuggen 
und nachher problemlos mit dem AVR-GCC kompilieren.