Bei Linux-32bit sind in C short-Variable 2 Byte groß. Gilt das auch bei Linux-64bit? Grund meiner Frage: In einem von mir erstellten Programm kommen an vielen Stellen Links-Shift-Operatonen mit anschließendem Rechts-Shift vor. Wenn die Variablen 2-Byte sind, kommen beim Rechts-Shift von links nur Nullen in diese 2 Bytes. Wenn die Variablen aber 4-Byte sind, kehren beim Rechts-Shift die zuvor nach links aus den unteren 2 Bytes hinausgeschobenen Bits in die unteren 2 Bytes zurück. Wenn ich das nicht will, muss ich vor dem Rechts-Shift ein ANDen mit 0xffff einfügen, damit mein Programm auch auf Linux-64bit läuft. Wenn ich sicher wüsste, dass die Variablen auch bei Linux-64bit 2-Byte sind, könnte ich mir das sparen. Selber habe ich nur Linux-32bit installiert und kann es nicht ausprobieren.
Josef G. schrieb: > Bei Linux-32bit sind in C short-Variable 2 Byte groß. > Gilt das auch bei Linux-64bit? Ja.
Würdest Du statt des nicht eineindeutig festgelegten Typs "short" den größenmäßig eindeutigen Typ int16_t verwenden, müsstet Du Dir keine Gedanken um das Thema machen. Ansonsten solltest Du noch mal genau darüber nachdenken, was die Kombination vorzeichenbehafteter Datentypen und Schiebeoperationen für "interessante" Effekte haben kann. Tip: Das Verhalten von << ist bei negativen Werten undefiniert.
Rufus Τ. Firefly schrieb: > Würdest Du statt des nicht eineindeutig festgelegten Typs "short" den > größenmäßig eindeutigen Typ int16_t verwenden, müsstet Du Dir keine > Gedanken um das Thema machen. Da er Nullen haben will schon. Da wäre er mit uint16_t besser dran. Aber das beantwortet nicht wirklich die Frage, denn hätte x86-64 kein 16-Bit "short", gäbe es kein (u)int16_t. Hätte er also auch nichts gewonnen. > Tip: Das Verhalten von << ist bei negativen Werten undefiniert. Meinst wohl >>.
A. K. schrieb: >> Tip: Das Verhalten von << ist bei negativen Werten undefiniert. > > Meinst wohl >>. Ist ziemlich egal. Ob links oder rechts, bei signed Typen weiss man nichts genaues. Will man auf Bitebene definiertes Verhalten, dann ist immer ein unsigned Datentyp das Mittel der Wahl.
Karl Heinz schrieb: > Ist ziemlich egal. Ob links oder rechts, bei signed Typen weiss man > nichts genaues. Andererseits warte ich immer noch auf jemanden, der mit eine leidlich aktuelle Maschine präsentiert (keine DSPs bitte), bei der >> nicht das Vorzeichen mit durchschiebt.
A. K. schrieb: > Karl Heinz schrieb: >> Ist ziemlich egal. Ob links oder rechts, bei signed Typen weiss man >> nichts genaues. > > Andererseits warte ich immer noch auf jemanden, der mit eine leidlich > aktuelle Maschine präsentiert (keine DSPs bitte), bei der >> nicht das > Vorzeichen mit durchschiebt. Schon richtig. Auf der anderen Seite ist es aber auch kein Beinbruch, gleich die richtigen Datentypen zu verwenden. Für viele C-Neulinge sind Datentypen ja mehr so etwas wie eine 'Dekoration im Programm'. Dem ist nun mal nicht so.
Danke für die Antworten. In meiner Anwendung geht es um unsigned short.
Gast
#3952375
auf der Zielplattform mal
1 | |
ausprobieren
Gast
#3952401
Peter schrieb: > auf der Zielplattform malprintf("%i", sizeof(unsigned short)); > ausprobieren soviel dazu: > Selber habe ich nur > Linux-32bit installiert und kann es nicht ausprobieren.
Peter schrieb: > auf der Zielplattform mal > ... > ausprobieren Eine entsprechende Abfrage hatte ich drin in meinem Programm zur Sicherheit, falls jemand das Programm auf Linux-64bit verwenden sollte. Das half mir aber bei meiner Frage auch nicht weiter, da ich nicht eigens Linux-64bit bei mir installieren wollte nur um die Frage zu beantworten.
Peter schrieb: > auf der Zielplattform mal > ... > ausprobieren Wenn er uint16_t verwendet ist das unnötig.
Gast
#3952449
uint16_t ist einfach beschissen im code zu schreiben. und rein aus komfort-zwecken: die Lesbarkeit des codes wird auch nicht verbessert. Gut im Texteditor machts keinen unterschied, aber ich persönlich habe keine IDE, die diese typen korrekt highligted. Borland, AVR Studio, AVR32 Studio, CodeLight... nichts. warum? weils einfach nur defines sind. ich hätte gerne mal irgendein system genannt, wo short nicht 16bit weit ist. oder wo ein char nicht 8bit weit ist.. oder wo ein long long int nicht 64 bit weit ist.... bei int / long int ists platformabhänig, aber auch eher architekturbedingt. Dort ists nur wichtig, wenn der code wirklich portierbar sein muss.. aber wer lässt AVR-Code denn auf x86 laufen? Wer das tut, weiß gut genug, dass die ints verschieden breit sind und wenn nicht, ist nach dem ersten debuggen die Stirn vom draufhauen rot. nichts was wirklich immens zeit kostet. von 1000 leuten die so hochprofessionell tuen und diese extra special datentypen_t verwenden... portieren wieviele auf eine andere platform, wo der code nich funktionieren würde? hmmh. 20 ? Und solang er kein 64-bit linux hat, wirds auch schwer für ihn das 64bit kompilat zu testen bzw zu debuggen. Pointergrößen sind da allemal mehr das Hinderniss.
... schrieb: > aber ich > persönlich habe keine IDE, die diese typen korrekt highligted. Bitte was? Bei mir funktioniert das einwandfrei... Atmel Studio 6.2, Visual Studio, KDevelop, QtCreator, alles kein Problem. ... schrieb: > uint16_t ist einfach beschissen im code zu schreiben. Was ist daran beschissen zu schreiben? unsigned long long ist deutlich beschissener zu schreiben als uint64_t. Aber dank autovervollstaendigung ist das eh wurst. ... schrieb: > die Lesbarkeit des codes wird auch nicht > verbessert. Aber natuerlich, weil jeder sofort sieht wie breit die Variable ist, voellig unabhaengig von der Architektur. ... schrieb: > bei int / long int ists platformabhänig, aber auch eher > architekturbedingt. eben, einfach (u)int32_t verwenden und alles ist gut, jetzt und in alle ewigkeit. Sorry, aber dein ganzer Post liest sich wie: Haben wir schon immer so gemacht, hat immer funktioniert, und wird nie geaendert. Neuerungen sind eh scheisse, weil ich mich umgewoehnen muesste, also bleibe ich im alten trott.
... schrieb: > ich hätte gerne mal irgendein system genannt, wo short nicht 16bit weit > ist. Irgendwelche DSPs. Und das olle Teil, das ich für Transputer schrieb. Weil keine Befehle dafür. Aber auf beidem gibts kein Linux.
Gast
#3952546
... schrieb: > und rein aus komfort-zwecken: die Lesbarkeit des codes wird auch nicht > verbessert. Gut im Texteditor machts keinen unterschied, aber ich > persönlich habe keine IDE, die diese typen korrekt highligted. Du schreibst also absichtlich unzuverlässigeren unvollständig definierten Code weil der korrekte Code nicht so hübsch gehighlightet wird? Du hast ja seltsame Prioritäten.
... schrieb: > von 1000 leuten die so hochprofessionell tuen und diese extra special > datentypen_t verwenden... portieren wieviele auf eine andere platform, > wo der code nich funktionieren würde? hmmh. 20 ? Die Portierung ist für mich noch nicht mal der Hauptgrund. unsigned char tippt sich nämlich noch beschissener als uint8_t; unsigned int tippt sich beschissener als uint16_t etc. etc. Und ich hab den Bonus, dass ich noch nicht mal über Bitgrößen gross nachdenken muss. > aber ich persönlich habe keine IDE, die diese typen korrekt highligted. Oh, mein Gott. Wir werden alle sterben! Äh nein. Als ich angefangen habe, gabs noch nicht mal eine IDE. Es gab auch kein Syntax-Highlighting aus dem simplen Grund, dass Farbe bei einem Computer nicht bezahlbar war (in vernünftiger Auflösung). Gut, es gab auch noch kein uint8_t. Aber das ist eine andere Story.
Karl Heinz schrieb: > Die Portierung ist für mich noch nicht mal der Hauptgrund. > unsigned char tippt sich nämlich noch beschissener als uint8_t; unsigned > int tippt sich beschissener als uint16_t etc. etc. Und ich hab den > Bonus, dass ich noch nicht mal über Bitgrößen gross nachdenken muss. Und weil das manchen Leuten alles zu blöd ist definieren sie typedef uint16_t u16; Viel kürzer gehts nicht. Sieht man öfter. > Äh nein. Als ich angefangen habe, gabs noch nicht mal eine IDE. Opa erzählt vom Krieg? ;-) Tja, mit den Möglichkeiten steigen die Ansprüche. Als ich anfing hatte das Display eine Zeile mit 20 Zeichen. Ging auch, aber Spass machte das schon damals eigentlich nicht. ASCII-Fernschreiber hatte ich aber keinen und Baudot-Fernschreiber waren zwar besser verfügbar, aber unpraktisch.
Gast
#3953304
Schön wäre es ja, wenn man nur int16_t nimmt, wenn man wirklich genau 16-Bit haben möchte. Sonst wäre int_least16_t besser, oder man bleibt gleich beim int.
Gast
#3953504
... schrieb: > uint16_t ist einfach beschissen im code zu schreiben. u i n...<autofill> <schwupp> t 16 _ t Bei mir ist es sogar bunt, weil als Keyword hinterlegt. Ok, in s/w vielleicht nicht so prickelnd. Komisch, ich verwende seit Jahren diese bezeichner, alle Finger noch dran. >Oh, mein Gott. Wir werden alle sterben! "Die Kunst des Krieges. Bekämpfe den Feind da, wo er nicht ist. Es hat endlich Klick gemacht. Nach all den Jahren." "Aber das bedeutet es nicht." "Ach Nein?" "Nicht mal annähernd."
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.