Hallo, ich meinem Code verwende ich int16_t, damit habe ich eine Stoppuhr. Diese zählt einmal werte positiv und dann auch negativ. Ich verwende int16_t was auch soweit funktioniert. Nun gewöhne ich mir eine andere Schreibweise an und wollte es mit short machen. Doch nun zählt er nur positiv aber nicht negativ. Ist short also nicht das gleiche wie int16_t ??
in der stdint.h steht:
/** \ingroup avr_stdint
8-bit signed type. */
typedef signed char int8_t;
/** \ingroup avr_stdint
8-bit unsigned type. */
typedef unsigned char uint8_t;
/** \ingroup avr_stdint
16-bit signed type. */
typedef signed int int16_t;
/** \ingroup avr_stdint
16-bit unsigned type. */
typedef unsigned int uint16_t;
short ist also int!
long schrieb: > Ich verwende int16_t was auch soweit funktioniert. Nun gewöhne ich mir > eine andere Schreibweise an und wollte es mit short machen. Nimm lieber die Schreibweise int16_t. Da weist du wenigstens genau, was du hast, wärend short / short int von der Implementation des Compilers und dem Zielprozessor abhängt. :-)
Man brauch keinen code. Ob bei deinem Compiler short == int ist, sagt dir das manual. Es ist aber aus portabilitäts Gründen besser bei int16_t, uint16_t usw zu bleiben. Nimm z.B. den Wertebereich Datentyp int: - 8051: -32768 bis 32767 - "PC": −2.147.483.648 bis 2.147.483.647
Nach allen Infos im Thread bisher ist die Beobachtung des TO für mich unverständlich. Es wäre interessant das betreffende Codestück zu sehen, um den Effekt zu reproduzieren oder zu falsifizieren.
> Nimm z.B. den Wertebereich Datentyp int: > - 8051: -32768 bis 32767 > - "PC": −2.147.483.648 bis 2.147.483.647 Bei den PIC CCS Compiler kann man int auch auf 8 Bit, also -128 .. +127 einstellen. Ich glaube sogar, das war die Default Einstellung. Und wie ist's bei ner 64 Bit Maschine ?
Situation: 1. Unklar, warum die Schreibweise "short" der Schreibweise "int16_t" vorgezogen werden soll. 2. Post mit Auszug von stdint.h in Beitrag "Re: short != int16_t" gibt keine Basis für die Schlussfolgerung das "short" das selbe wie "int" ist. Insbesondere wird durch den Auszug aus stdint.h nicht geklärt ob "short" wie "int" vorzeichenbehaftet ist. Information: 1. "short" ist als "int"-Typ vorzeichenbehaftet. Siehe: http://de.wikipedia.org/wiki/C_%28Programmiersprache%29#Basisdatentypen und http://openbook.galileocomputing.de/c_von_a_bis_z/005_c_basisdatentypen_006.htm#mjbac145b7d1ec17dbb4096f2a1c1a616b sowie deren Referenz http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf Seite 22 und andere.
Dieser Thread ist ein weiterer beeindruckender Beweis, warum (u)intxx_t soviel eindeutiger sind - auf jedem Compiler und auf jeder CPU!
Herbert Hebert schrieb: > (short) int = 8 Bit. In Standard-C hat short mindestens 16 Bits und hat selbstredend ein Vorzeichen. stdint.h hilft dabei nicht sehr, limits.h und dessen ANSI-Vorgabe hingegen schon.
Um hier mal die Rätselraterei abztustellen ("int 8 bit?", "short ohne
Vorzeichen?", "short größer als int?"):
In ISO-C ist gibt es folgende Integer-Typen:
char
short
int
long
long long
Die gibt es jeweils mit und ohne Vorzeichen. Außer char hat jeder dieser
Typen ein Vorzeichen, wenn kein "unsigned" davor steht. Bei char ist es
Compiler-spezifisch, ob es ohne weitere Angabe mit oder ohne Vorzeichen
ist.
Es gilt
sizeof(char) = 1
sizeof(short) >= sizeof(char)
sizeof(int) >= sizeof(short)
sizeof(long) >= sizeof(int)
sizezof(long long) >= sizeof(long)
Außerdem muß char mindestens 8 Bit breit sein, short und int mindestens
16 Bit, long mindestens 32 Bit und long long mindestens 64 Bit. Diese
Anforderung steht zwar nicht direkt so in der ISO-Norm, ergibt sich aber
aus den Anforderungen an die mindestens zu untersütztenden Wertebereiche
dieser Typen.
Alles, was von den obigen Bedingungen abweicht, verstößt gegen die
ISO-C-Spezifikation.
Floh schrieb:
> long schrieb:
>> Ich verwende int16_t was auch soweit funktioniert. Nun gewöhne ich mir
>> eine andere Schreibweise an und wollte es mit short machen.
>
> Nimm lieber die Schreibweise int16_t. Da weist du wenigstens genau, was
> du hast,
Sofern es wirklich unbedingt exakt 16 Bit sein müssen und auf gar keinen
Fall mehr sein dürfen. Ansonsten wäre je nach Anforderung int_fast16_t
oder int_least16_t vorzuziehen.
Art Ickel aus W. schrieb:
>> Nimm z.B. den Wertebereich Datentyp int:
>> - 8051: -32768 bis 32767
>> - "PC": −2.147.483.648 bis 2.147.483.647
>
> Bei den PIC CCS Compiler kann man int auch auf 8 Bit, also -128 .. +127
> einstellen. Ich glaube sogar, das war die Default Einstellung.
Bei avr-gcc kann man das auch so einstellen, vor allem, weil der
Compiler hier ein paar Defizite bei der Optimierung hat. Es wird aber
trotzdem selten verwendet, da es mehr Probleme verursacht als es löst.
Es ist wie gesagt auch nicht konform.
> Und wie ist's bei ner 64 Bit Maschine ?
Unterschiedlich. Nach ISO C sollte (muß aber nicht) int 64 Bit breit
sein, da das die native Wortbreite der Maschine ist. Das wird aber in
der Regel nicht gemacht, da einem dann nach unten hin die Typen
ausgehen. Man will ja auch 8, 16, und 32 Bit haben, hat aber nur zwei
Typen, die kleiner als int sein dürfen, nämlich char und short. Deshalb
ist int dort in der Regel auch 32 Bit, short 16 Bit und char 8 Bit. Bei
long gibt es dann Unterschiede. Auf manchen 64-Bit-Systemen ist long 32
Bit breit, auf anderen 64 Bit. Ob es bei letzteren auch üblich ist, long
long 128 Bit breit zu machen, ist mir allerdings nicht bekannt.
long schrieb: > Ich verwende int16_t was auch soweit funktioniert. Nun gewöhne ich mir > eine andere Schreibweise an und wollte es mit short machen. Doch nun > zählt er nur positiv aber nicht negativ. Bleib bei int16_t - dein Code bleibt dadurch wesentlich portierbarer. Falls es nicht auf die Größe ankommt ist es natürlich effizient die für die Plattform günstige Größe zu nehmen. Sollte man sich dann sowas wie uintstd_t und intstd_t definieren, mit der Vereinbarung dass diese auf jeder Plattform mindestens 16-bit hat.
Klaus schrieb: > Bleib bei int16_t - dein Code bleibt dadurch wesentlich portierbarer. > Falls es nicht auf die Größe ankommt ist es natürlich effizient die für > die Plattform günstige Größe zu nehmen. Sollte man sich dann sowas wie > uintstd_t und intstd_t definieren, mit der Vereinbarung dass diese auf > jeder Plattform mindestens 16-bit hat. dafür gibt es doch die fast typen uint16_fast_t zB muss mindestens uint16_t sein kann aber größer sein, wenn dies schneller auf der Zielplatform ist.
Hab ich ja schon geschrieben. Eigentlich ist das sogar portabler, wenn's auch in der Praxis selten eine Rolle spielt. Wenn es auf dem Zielcompiler keinen 16-Bit-Typ gibt, dann gibt es da nämlich auch keinen uint16_t, aber einen uint_fast16_t gibt's.
Wie gebe ich denn die stdint-Variablen mit printf aus, wenn ich nicht genau weiß wie groß diese sind? Casting nach long, oder gibt es eine bessere Möglichkeit?
In inttypes.h sind Definition für Format-Spezifizierer der in stdint
definierte Typen enthalten.
Z.B. für printf:
/** \ingroup avr_inttypes
decimal printf format for int8_t */
#define PRId8 "d"
Siehe auch:
http://openbook.galileocomputing.de/c_von_a_bis_z/005_c_basisdatentypen_007.htm#mjdc3fe710a0f3af27e81228931f8e6bcb
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.