C++ igen - storlekar på variabler [LÖST]

[Johnny Rosenberg]

Har ju förstått att en variabel som deklarerats som exempelvis long inte nödvändigtvis består av lika många bytes i alla system, men vad är det som gör skillnaden? Är det hårdvaran? Kan en long vara ett annat antal bytes på laptop A jämfört med laptop B? Har det med om man använder Intelprocessor eller exempelvis AMD att göra? Eller spelar operativsystemet roll? 32-bitarsprocessor kontra 64-bitars?

Ett litet problem uppstår ju lätt som jag försöker fundera ut hur man kommer runt:
Anta att jag skriver ett program som jag vill ska kunna köras på alla datorer oavsett det mesta. Programmet skapar binärfiler av något slag. Då går det ju inte an att en dator skriver en variabel i filen med 4 bytes medan en annan använder 8. Hur ska då filerna kunna läsas och tolkas i de olika systemen? Finns det ingen standard som reglerar detta? Fast hade det funnits det, så hade ju inte saker som sizeof och liknande varit nödvändiga...

Eller om jag nu skriver ett program som hanterar wav-filer, måste jag då skriva om mitt program om det visar sig att en long är 4 bytes på ett system, medan int är 4 bytes på ett annat, för att kunna köra mitt program på det andra systemet?

Eller kort sagt: Hur ska man egentligen förhålla sig till detta?

J.R.

[Lars]

I C99 finns numera <stdint.h> med uint16_t och liknande typer, jag antar att man kan använda dem i C++ också.

[Johnny Rosenberg]

Verkar vara precis vad jag är ute efter. Hade inte hört talas om C99 förut, men det pratades mycket om C++ på sidan din länk tog mig till. Ska testa den. Tack!

Någon som kan svara på när man kan förvänta sig att storleken på exempelvis en int skiljer sig mellan två system?

[mcNisse]

På ett 32 bitars system och ett 64 bitars.

[Lars]

Någon som kan svara på när man kan förvänta sig att storleken på exempelvis en int skiljer sig mellan två system?

På en TMS320VC33 har jag för mig att char, short, int och long alla är 32 bitar långa. Det finns många udda system.

[Johnny Rosenberg]

Så om man ska se krasst på det hela, så är alla heltalstyper inklusive char bara att glömma om man vill skriva ett program som garanterat går att kompilera och köra på alla system under alla omständigheter?

J.R.

[Lars]

Det beror väl på ... 64-bitars operationer kan ju bli relativt långsamma på en 32-bitars processor, så man kanske vill använda native-storleken. Men det är ju alltid bra att använda INT_MIN/INT_MAX etc. från <limits.h> och kontrollera att man inte överskrider några gränser. Typ så här:

Kod: Markera allt

if(idx >= UINT_MAX)
  printf("ERROR");

Och om man har speciella krav kan ju åtminstone varna för det:

Kod: Markera allt

#if UINT_MAX < ((2 << 32) - 1)
#error Du måste ha minst 32-bitars int för att kompilera detta program
#endif

Men det är ju svårt att skriva portabel kod för en helt okänd arkitektur, det är nog snudd på omöjligt.

[Johnny Rosenberg]

Men det är ju svårt att skriva portabel kod för en helt okänd arkitektur, det är nog snudd på omöjligt.

Det kanske går om man väljer något annat programmeringsspråk...

[gasol]

Förstår inte var problemet är egentligen?

intN_t and uintN_t.
* Both types must have no padding bits.
* intN_t must be encoded as a two's complement signed integer.

Så en uint32_t kommer alltid att vara 4 bytes och 32 bitar på alla system som stödjer detta...

Om en plattform inte ens kan stödja detta så kanske det är inte är värt mer arbetet att utöka programmet för att stödja den plattformen.

64-bitars operationer kan ju bli relativt långsamma på en 32-bitars processor.

Detta är väl ändå att ta i? Jag menar det enda som händer väl att en shiftning på 32 steg utförs i FPU:n
Det kommer ju alltid att finnas ställen i ditt program du kommer att behöva använda just 32 bitars heltal,
inläsning av binära filer te.x.

[Lars]

64-bitars operationer kan ju bli relativt långsamma på en 32-bitars processor.

Detta är väl ändå att ta i? Jag menar det enda som händer väl att en shiftning på 32 steg utförs i FPU:n

T.ex. division av 64-bitars tal på en 32-bitars processor kräver ju lite mer än en skiftning. Om beräkningen dessutom ligger i en loop och ska beräknas många gånger kan det ha stor betydelse. Ännu värre är det ju att räkna med 8-bitars tal på en processor som inte stödjer det, bara för att spara lite minne. Det är ju totalt onödigt eftersom en större datatyp fungerar lika bra.

Men de senaste åren har jag utvecklat och implementerat signalbehandlingsalgoritmer i realtid, så jag har kanske en liten annan syn på saken. En enda extra instruktion inuti i loop kan ställa till det ordentligt. När man programmerar desktop-program får man ju fokusera på andra aspekter än för inbäddade system.