Perché sono stati inventati short, int e long in C?


16

Sto avendo difficoltà a capire, quali sono stati gli obiettivi dei creazione del short, intelong tipi di dati in C?

Il motivo per cui chiedo è che non sembra che le loro dimensioni siano limitate: potrebbero essere di qualsiasi dimensione, purché shortsiano più piccole di unint , per esempio.

In quali situazioni, quindi, dovresti usare un unsigned into unsigned long, ad esempio, invece di un size_t, quando farlo non offre alcuna speranza di compatibilità binaria?

(Se non conosci le dimensioni, come sapresti quando scegliere quale?)


2
Scopri<stdint.h>
BlackJack,

1
@ Black Jack: Ah ah sì, in realtà ce l'ho - ma credo che la mia domanda sia: perché non sono tutti definiti in modo nativo invece? È un problema "il senno di poi è 20/20" o c'era un motivo specifico?
user541686,

2
C doveva essere portatile e vicino all'hardware sottostante. Esistevano piattaforme in cui il byte non era lungo 8 bit, ma era ancora possibile utilizzare C. Nessun set di tipi di dati fissi sarebbe mai stato sufficiente, nessun integere a dimensione fissa non sarebbe mai stato portatile.
SK-logic,

@ SK-logic: Neanche se dicessero sizeof(short) == 2 * sizeof(char)o simili?
user541686,

1
Ci sono piattaforme dove sizeof(char) == sizeof(short)e ha senso. Sfortunatamente, non esiste alcun modo per specificare i tipi di numeri integrali in modo che possano adattarsi a tutte le piattaforme possibili ed esistenti.
SK-logic,

Risposte:


12

Sarebbe definito dall'architettura che stavi usando. Su un chip Zilog z80 (comune chip incorporato) avrebbero una dimensione mentre potrebbero essere completamente diverse su un chipset x86. Tuttavia, le dimensioni stesse sono rapporti fissi tra loro. Essenzialmente short e long non sono tipi ma si qualificano per il tipo int. Gli short short saranno di un ordine di grandezza più piccoli di (normali) int e quelli più lunghi saranno di un ordine di grandezza più alto. Quindi supponiamo che il tuo Int sia limitato a 4 byte, il qualificatore breve lo limiti a 4 byte anche se 2 byte è anche molto comune e il qualificatore lungo lo potenzia potenzialmente a 8 byte sebbene possa essere inferiore a 4 byte. Tieni presente che questo è soggetto anche alla lunghezza delle parole, quindi su un sistema a 32 bit dovresti raggiungere il massimo a 4 byte per int facendo comunque la stessa cosa di un normale int. Pertanto, Short ≤ Int ≤ Long.

Tuttavia, se lo allunghi di nuovo, puoi inserire int nella cella successiva fornendo 8 interi byte di spazio di archiviazione. Questa è la dimensione della parola per le macchine a 64 bit, quindi non devono preoccuparsi di tali cose e usano solo una cella per i long ints permettendo loro di essere un altro ordine sopra gli standard ints mentre i long ints diventano davvero bit.

Per quanto riguarda quale scegliere, si riduce a qualcosa di cui i programmatori Java, ad esempio, non devono preoccuparsi. "Qual è la tua architettura?" Poiché tutto dipende dalla dimensione della parola della memoria della macchina in questione, è necessario capirlo prima di decidere quale utilizzare. Quindi scegli la dimensione ragionevole più piccola per risparmiare quanta più memoria possibile perché quella memoria verrà allocata indipendentemente dal fatto che tu usi tutti i bit in essa contenuti. Quindi risparmi dove puoi e scegli i pantaloncini quando puoi e quando non puoi e se hai bisogno di qualcosa di più grande di quello che fai regolarmente; allungheresti quanto basta fino a quando non colpisci la parola soffitto. Quindi avresti bisogno di fornire routine di grandi numeri o ottenerli da una libreria.

C potrebbe essere un "assemblaggio portatile" ma devi ancora conoscere il tuo hardware.


11
questo non è del tutto corretto, i pantaloncini non devono essere più piccoli degli ints, non possono essere più grandi degli ints
jk.

Lo correggerò.
Ingegnere mondiale,

2
Allo stesso modo, i long non possono essere più piccoli degli ints.
Donal Fellows,

1
anzi credo che ci siano state macchine in cui short, int e long erano esattamente le stesse.
jk.

6

Anche se oggi, un "byte" significa "8 bit", che non è sempre stato vero. Le macchine hanno usato blocchi indirizzabili di 4 bit, 8 bit, 12 bit, 16 bit, 32 bit e 36 bit (e probabilmente anche di altre dimensioni). Una delle intenzioni progettuali di C era quella di essere utilizzabile su macchine con diverse dimensioni e configurazioni di memoria.

Penso che l'intenzione progettuale fosse originariamente che ogni tipo diverso da quello intfosse la cosa più piccola in grado di gestire numeri di varie dimensioni, e quelloint fosse la dimensione "per tutti gli usi" più pratica che potesse gestire +/- 32767. Non penso che ci fosse alcun desiderio o intenzione di creare un linguaggio che sarebbe ancora in uso quando i computer diventassero così potenti che le operazioni sui numeri a 64 bit costano come quelle su quelli più piccoli.

Il problema più grande con la semantica di tipo intero di C è che in alcuni contesti rappresentano numeri cardinali o interi matematici, mentre in altri contesti sono usati per rappresentare membri di un anello algebrico astratto avvolgente di interi congruenti mod 2 ^ n [quindi ad esempio sottrarre il valore massimo rappresentabile da 0 è definito per produrre 1], ma i comportamenti sono specificati di più sulla base di ciò che i compilatori sembrano fare nei giorni in cui le dimensioni delle parole del computer erano intorno a 16 bit (e una dimensione delle parole di 36 bit sarebbe stata enorme ), piuttosto che sulla base di ciò che avrebbe senso su una macchina a 64 bit. Di conseguenza, il risultato della sottrazione di un valore senza segno a 32 bit da un valore senza segno a 32 bit più piccolo può essere un valore senza segno a 32 bit di grandi dimensioni o un numero negativo a 64 bit.


4

/programming/589575/size-of-int-long-etc

Quindi nelle architetture più comunemente usate, char è 1 byte, short e int sono almeno 2 byte e long è almeno 4 byte.

Ed è inteso che 'int' dovrebbe essere la rappresentazione più naturale / normale / efficiente per la CPU corrente.

Quindi la regola generale è usare 'int' a meno che i tuoi valori non superino +/- 32K, facendoti (su CPU più vecchie) usare 'long'. ... o a meno che tu non stia creando grandi array di valori piccoli (<32K) e la memoria sia un problema, quindi useresti "short" per risparmiare memoria (o forse "char" o "byte").


2
Ma con 64 bit, intnon è quasi mai una buona scelta, giusto? Quasi sempre finisco per usare size_t(o anche ptrdiff_t!) Comunque, per evitare problemi con il codice di porting.
user541686,

@Merhdad - int era abituato alla scelta migliore per cui si trattava dell '"unità standard" dell'HW, e in genere la dimensione di un puntatore. Al giorno d'oggi usa size_t per sicurezza.
Martin Beckett,

1

C è stato progettato per gestire attivamente la memoria a diversi livelli. Ci sono casi in cui la differenza tra short, int e long, e tra float e double, contava a causa dei vincoli di memoria, dell'architettura, ecc. Sebbene contenga meno ora, ci sono ancora ambienti in cui lo fa (ad esempio, incorporato e in casi in cui i dati sono enormi) e il passaggio da architetture principalmente a 32 bit a 64 bit lo rende nuovamente un problema. (Tra dieci o venti anni quando passeremo alle architetture a 128 bit e C / C ++ è ancora popolare, sarà di nuovo un problema). Hai ragione però che soffre di compatibilità binaria, motivo per cui non vuoi usare queste dimensioni di tipo variabile dove è importante.

Hai chiesto come sapresti quale utilizzare se non conosci la dimensione, ma conosci la dimensione su una data combinazione architettura / compilatore e se hai bisogno di ottimizzare la memoria a quel livello, è meglio conoscerla. Non puoi ottimizzarlo semplicemente su tutte le piattaforme perché non puoi conoscerne le dimensioni, quindi non vorrai utilizzare tali funzionalità a tale scopo. Ma molte cose scritte in C sono specifiche della piattaforma, che, nonostante la moda per "cross platform", consente alcune ottimizzazioni vantaggiose.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.