Newsgroup: it.comp.lang.c
Titolo: E se dovessi gestire interi più grandi di 2^32 ?

Ciao a tutti,
volevo sapere: se dovessi gestire numeri interi pių grossi di 2^32 (il tipo
long int dovrebbe corrispondere a 4 byte giusto?) come faccio?
Esistono altri tipi di dati interi pių grandi?
Grazie
Bye
John

 Esistono altri tipi di dati interi più grandi?
long long
Non tutti i compilatori (specie quelli piu' vecchi) lo supportano.
Altri (tipo VC++ 5) supportano tipi proprietari (__int64)
HTH
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Esistono altri tipi di dati interi più grandi?
in diversi compilatori moderni esiste un tipo di dato a 64 bit.
Non e' detto che sia portabile, ma non mi sembra questo il
tuo problema al momento.
Il nome di questo tipo puo' dipendere dal compilatore che usi:
se fosse il gcc sarebbe "long long int"
in altri compilatori per windows potrebbe essere qualcosa
tipo __int64 ma devi controllare nell'help sui tipi elementari
specifici del tuo compilatore.
Se ti servono numeri ancora piu' grandi allora o ti costruisci da solo
un tipo opportuno (simulandolo con operazioni su tipi piu' piccoli)
o usi una libreria gia' scritta da gente tosta per manipolare numeri
interi in precisione arbitraria, per esempio la gmp:
http://www.swox.com/gmp/
ciao,
g.

Grazie ad entrambi, penso che per adesso mi accontenterò di interi a 64bit!
Bye
John

 il tipo long int dovrebbe corrispondere a 4 byte giusto?
No, il tipo long int corrisponde a "sizeof (long int)" byte, che puo` 
essere un qualsiasi valore intero >= 1.
Ad esempio, su una macchina a 64 bit il long int potrebbe essere di 8 
byte. L'operatore sizeof esiste appunto perche` le dimensioni dei tipi 
non sono specificate dallo standard.

 essere un qualsiasi valore intero >= 1.
Vabbé non volevo esprimere una verita assoluta per il cosmo intero.
Riformulerò la mia affermazione:
"il tipo long int sulla mia macchina con architettura a 32bit e sistema
operativo Windows 2000 corrisponde ad una variabile di intero di dimensione
pari a 4 byte giusto?".
Bye
John

 pari a 4 byte giusto?".
Dipende dal compilatore. Con un compilatore a 32 bit, probabilmente si`. 
Se usi il vecchio Turbo C per DOS, allora no, sono di 2 byte. Ma tutto 
cio` e` irrilevante, se vuoi scrivere programmi portabili.

 Se usi il vecchio Turbo C per DOS, allora no, sono di 2 byte.
Pardon, mi sono confuso con gli int.

Enrico `Trippo' Porreca wrote:

Questa affermazione è parimenti errata.
Lo standard specifica parzialmente alcune dimensioni, ad esempio al
paragrafo 5.2.4.1, Lo standard ISO/IEC 9899:1999 (aka c99) dice:
       [#1]  The  values  given below shall be replaced by constant
       expressions  suitable   for   use   in   #if   preprocessing
       directives.   Moreover,  except for CHAR_BIT and MB_LEN_MAX,
       the following shall be replaced by expressions that have the
       same  type  as  would an expression that is an object of the
       corresponding  type  converted  according  to  the   integer
       promotions.   Their  implementation-defined  values shall be
       equal or greater in  magnitude  (absolute  value)  to  those
       shown, with the same sign.
       [...]
         -- minimum value for an object of type long int
            LONG_MIN               -
2147483647
 // -(2^31-1)
         -- maximum value for an object of type long int
            LONG_MAX               +2147483647 // 2^31-1
Quindi sizeof(long int) deve essere *almeno* 4.
Ma lo standard si spinge anche più avanti, ad esempio il tipo "int", oltre a
coprire un range minimo di valori uguale a quello di long, possibilmente
deve anche avere la dimensione naturale dell'architettura hardware:
       A ``plain'' int object has the natural size suggested by the
       architecture of the execution environment (large  enough  to
       contain any value in the range INT_MIN to INT_MAX as defined
       in the header <limits.h>).
Quindi su un'architettura ia32 (aka x86) il tipo int deve essere
*esattamente* 4 bytes.
Detto questo, rimane valida l'osservazione secondo la quale nessun serio
programmatore C darebbe per scontata la dimensione di un tipo e l'uso del
typeof e sempre e comunque estremamente consigliabile.


Neanche per sogno. Se CHAR_BIT e` pari a 32, sizeof (long int) puo` 
essere pari ad 1.
Esistono diverse architetture embedded in cui CHAR_BIT e` 16, quindi 
sizeof (long int) puo` valere 2.
Stai dando per scontato che un byte sia di 8 bit. Per quanto riguarda lo 
standard C (dove un byte e` la dimensione di un char) questo non e` 
necessariamente vero, un byte e` grande esattamente CHAR_BIT bit (un 
numero intero >= 8, come puoi leggere nella stessa sezione che citi).

 typeof e sempre e comunque estremamente consigliabile.
Io non davo per scontato proprio niente....
ho solo dimenticato di mettere il sottotitolo "Nel mio caso specifico"....
a me interessava sapere se esisteva il modo di memorizzare valori più grandi
di 2^32, non ho fatto nessuna affermazione su quello che un programmatore
deve o non deve dare per scontato.
Punto
Bye
John


Impara a quotare e ad attribuire le citazioni: quella frase non l'ho 
scritta io.

 *esattamente* 4 bytes.
Piccola annotazione, visto che stiamo per entrare nel mondo dei 64 bits. Si
sta parlando di ignorare questa regola (che non č una regola, ma un
suggerimento) e per questioni di retrocombatibilitŕ con i programmi lasciare
gli int a 32 bits (il 99% dei sistemi desktop attuali hanno gli int con 32
bits ora). Questo per lo meno nel mondo Windows.
--- bye

 int con 32 bits ora). Questo per lo meno nel mondo Windows.
Non se ne sta solo parlando: gcc sul mio processore Athlon64 compila gli int
a 32 bit.

 essere pari ad 1.
Nonostante la mia imprecisione, la tua affermazione rimane testardamente
errata: lo standard specifica parzialmente alcune dimensioni. ;)

 bits ora).
Non e` una vera e propria regola. In ogni caso gli x86 possono trattare
indifferentemente interi di 8, 16, 32 bit, senza perdite di prestazioni.
Per la cronaca su x86-64, anche nella modalita` a 64 bit, la dimensione
di default degli operandi e` di 32 bit. Per usare operandi a 64bit
bisogna usare l'apposito prefisso.
Luca
-- 
Home: 
http://kronoz.cjb.net
The trouble with computers is that they do what you tell them, 
not what you want.
D. Cohen


Ma che palle!
Avevo lasciato una riga per sbaglio ma si capiva benissimo a chi mi
riferivo!
Bye
John

 riferivo!
Il problema e` il seguente: se conosci come funziona Usenet, sai 
certamente che una persona potrebbe leggere la tua risposta prima del 
mio post (che puo` non essere ancora disponibile sul suo server). Se 
attribuisci il messaggio ad una persona diversa dall'autore, si possono 
originare fraintendimenti (in questo caso in particolare non e` 
importante, in altri magari si`).
Quindi non volermene, non volevo certo offenderti con quello che ho 
scritto, ma soltanto segnalarti una svista.