Newsgroup: it.comp.lang.c++
Titolo: curiosità su processore a 64 bit

Mi scuso se questo post non è propriamente in topic con il
gruppo, ma la mia è solo una curiosità.
Con un processore a 64 bit (tipo il Merced della Intel)
quanti bit ha un char? Che grandezza hanno tutte le altre
variabili?
Mi interessa perchè se il char diventa a 16 bit risolverebbe
tutte le problematiche relative a scrivere applicazioni
per Unicode.
Se invece il char resta a 8 bit, il tipo short int presumo sia
di 32 bit (dato che int è di 64 bit).
Quindi per interi a 16 bit come si fa?
short short int?
Saluti e grazie   Manlio Perillo

per Unicode.
per questo basta che utilizzi un linguaggio come Java ^_^
--
Rhymes
rhy...@myself.com
http://www.foxhound-games.it

 variabili?
credo che dipenda piu' dall'OS e dal compilatore che dalla CPU: gia' 
ora molti compilatori hanno variabili a 64 bit pur essendo nati per 
processori a 32 bit

 variabili?
Noi abbiamo nel nostro cluster sette Dec-Alpha a 64 bits; da un
cinque-sei anni, credo.  Le dimensioni delle variabili dipendono dal
compilatore; per g++ un char ha 8 bits, uno short 16, un int 32 ed un
long 64 bits.
-- 
Maurizio Loreti                         
http://www.pd.infn.it/~loreti/mlo.html
Univ. of Padova, Dept. of Physics - Padova, Italy            
lor...@pd.infn.it

 per questo basta che utilizzi un linguaggio come Java ^_^
[FLAME ON]
E poi distribuire l'applicativo devi distribuire anche
la Java Virtual Machine :-)
[FLAME OFF]
Bando alle polemiche:
Perche' usare std::wstring no ?
Ciao
Gaetano.
-- 
Posted from 
dell-01.mm.eutelsat.org
 [194.214.173.17] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 variabili?
Che cosa vuol dire affermare che un processore e' a 64 bit?
Sostanzialmente, coincide con il dire che la quantità elementare di dati
(il dato elementare o l'istruzione di programma) scambiata dal
processore con la memoria in un unico "trasferimento" (e gestita in un
singolo registro interno) e' costituita di 64 bit. Il significato di
questi 64 bit dipende interamente dal contesto. Un compilatore (come
ogni altro programma) puo' usare una parte di questo pacchetto di 64
bit, o un numero qualisiasi di questi pacchetti di 64 bit per
memorizzarvi una variabile di un "tipo" qualsiasi. Se a certi tipi e'
standard associare una certa configurazione di bit, e se tale standard
e' effettivo ed efficace, probabilmente a quel tipo continuera' ad
essere associata la stessa configurazione di bit, indipendentemente
dalle caratteristiche (e quindi dal numero di bit della sua "parola
elementare") del processore.
Chissa' se sono riuscito a spiegarmi (e se non ho detto troppe
castronerie). Ciao.

 short short int?
Ovviamente per le lunghezze non supportate direttamente dai tipi ISO si
useranno estensioni dei compilatori. Alcuni inseriranno short short (ma
nota che teoricamente non è del tutto standard). Altri (credo la maggior
parte) useranno altri nomi riservati. Nomi gettonati (se non altro
perchè già supportati dai compilatori 32 bit di MS) sono __int8,
__int16, __int32, __int64. Ai quali probabilmente si aggiungerà __int128
e forse __int256. Simili estensioni sono usate anche per rappresentare i
tipi speciali usati per i calcoli multi operando (per esempio nelle
applicazioni multimediali) su piattaforme intel (MMX) o AMD (3DNow).
Attualmente i nomi validi per VC sono __m64, __m128, __m128i e __m128d.
Altre opzioni (sempre provenienti dal mondo MS) sono le estensioni ai
tipi definiti nelle librerie di windows. I nomi sono quelli classici
tutti maiuscoli con alcune aggiunte. Alcuni esempi sono: BYTE, WORD,
DWORD, DWORD32, DWORD64, INT32, INT64, UINT32, UINT64, ULONG32, ULONG64,
BOOL, SIZE_T, SSIZE_T, DWORD_PTR, INT_PTR, LONG_PTR, HALF_PTR,
POINTER_32, POINTER_64 e altre simili (nota: non confondete INT_PTR che
è un intero grosso abbastanza da poter tenere un puntatore con PINT che
è un puntatore ad intero).
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556

 singolo registro interno) e' costituita di 64 bit.
Generalmente vero. Ma non è detto. I 386SX per esempio scambiavano i
dati a colpi di 16 bit, ma erano dei processori a 32 bit. In altre
architetture piò moderne i processori non scambiano dati con la memoria
ma con una cache interna al processore la quale scambia i dati con una
cache esterna la quale scambia i dati con la memoria. E questi scambi
avvengono normalmente a blocchi di parecchi byte.
Altre misure più comuni si riferiscono alla dimensione minima di
incremento decremento dello stack pointer, che in una architettura a 64
bit è quasi certamente di 8 byte. Ma alcune macchine potrebbero
permettere l'inserimento e l'eliminazione dallo stack di soli 4 byte.
Sarebbero considrate macchine con lo stack nativo a 64 bit perchè le
istruzioni per lavorare con 64 bit per volta sullo stack saranno molto
più corte e veloci rispetto a quelle per lavorare con 32 bit.
Allo stesso modo si può ragionare per i calcoli fra interi (nei registri
interni). Se l'architettura della ALU e quella dell'indirizzamento dei
registri si basa su una dimensione di 64 bit allora:
1) istruzioni che manipolano meno di 64 bit sono possibili. Saranno più
lunghe o lunghe uguali a quelle che manipolano 64 bit. Eseguiranno alla
stessa velocità.
2) istruzioni che manipolano più di 64 bit sono possibili. Saranno più
lunghe o lunghe uguali a quelle che manipolano 64 bit. Eseguiranno più
lentamente.
Nota che è concepibile un processore avente architettura a 64 bit ma
avente queste caratteristiche:
1) calcoli fra interi a 32 bit eseguiti alla stessa velocità di quelli a
64 bit e con istruzioni della stessa lunghezza
2) movimentazione dati fra cache e registri coinvolgenti 32 bit eseguita
alla stessa velocità di quella a 64 bit e con istruzioni della stessa
lunghezza
3) movimentazione dati tre registri a 32 bit e lo stack (anche se sullo
stack il registro a 32 bit viene rappresentato usando 64 bit) eseguite
alla stessa velocità di quelle a 64 bit e con istruzioni della stessa
lunghezza
In questo caso l'architettura è certamente a 64 bit (l'uso di 64 bit non
peggiora le performance rispetto all'uso a 32 bit e addirittura lo stack
potrebbe essere fisicamente a 64 bit). Nonostante questo sia interi a 32
bit che interi a 64 bit vanno considerati nativi all'architettura (e
potenzialmente un compilatore porebbe avere sizeof(int)==4).


 bit è quasi certamente di 8 byte. Ma alcune macchine potrebbero
Un' altra definizione era : il numero di bit del registro accumulatore.
Per cui sui 386 era 32 bit, sui 8086 16 bit, sui MIPS anche a 128bit etc 
etc...
-- 
FUSION (fyu zh & n) n: 
1) the Act or Process of Fusing or Melting Together... 
2) the State of being Fused... 
3) to Join or become Combined...


Per un processore a 64 bit mi aspetterei un int a 64 bit.
Ciao  Manlio Perillo


Molto più comodo avere un char già di 16 bit, no?
Ancora grazie e ciao   Manlio Perillo

 Per un processore a 64 bit mi aspetterei un int a 64 bit.
Non e' detto, l' ee-gcc (il compilatore per il mips della PS2 a 128bit) ha 
gli int a 32bit. E ti assicuro che sono molto piu' semplici da gestire :-)
God bless 32 bit integer :-)


 Per un processore a 64 bit mi aspetterei un int a 64 bit.
Il codice a 32-bit nasce e muore a 32-bit. Non è che metterlo a funzionare
su una macchina a 64-bit lo trasforma magicamente in un codice a 64-bit.
Quella cifre dipendono dalle specifiche del linguaggio, e per quelle esiste
un organismo di standardizzazione: l'ANSI/C e ANSI/C++. Esistono varianti a
64 bit dei linguaggi di programmazione, non linguaggi che si adattano alle
macchine.
Un programmatore qualificato non avrebbe mai posto una simile domanda.
ciao, e buon delirio a tutti

 Per un processore a 64 bit mi aspetterei un int a 64 bit.
In effetti sarebbe ragionevole, ma penso che ci si sia preoccupati di
non rompere codice che assumesse int di 32 bit.
Ciao,
Nicola

 Attualmente i nomi validi per VC sono __m64, __m128, __m128i e __m128d.
Lo standard C 99 prevede dei nomi di tipi facoltativi per indicare
interi di dimensioni specifiche o comunque vincolate, come int32_t e via
dicendo. Mi pare plausibile che vengano accettati anche nello standard
C++.
Ciao,
Nicola

 Un programmatore qualificato non avrebbe mai posto una simile domanda.
viste le dichiarazioni farneticanti di molte societa' riguardo ai nuovi 
prodotti e' normale che qualcosa sia poco chiaro.
E poi un programmatore qualificato non userebbe mai outlook express ;)

 Un programmatore qualificato non avrebbe mai posto una simile domanda.
A quanto pare impazzito sei tu. Manlio, che per inciso e' una delle
persone piu' competenti che frequentano il newsgroup, ha espresso una
curiosita' legittima e di buon senso, come dimostra la discussione che
ne e' nata.
A proposito di qualifiche, pare che del C++ tu non conosca nemmeno le
basi...
Ciao,
Nicola

 ciao, e buon delirio a tutti
Ancor...Senti se voui ti puoi iscrivire alla ML "delirio" (si esiste, ci 
sono dentro anche io ovviamente) visto che ti sta a cuore l' argomento :-)


 Il codice a 32-bit nasce e muore a 32-bit.
Cosa e' il "codice a 32 bit"?  Il C++ (di cui si occupa questo NG) non
fa assunzioni sulla lunghezza in bits dei tipi aritmetici.  Quello che
lo standard C++ richiede e', ad esempio, che un char sia di ALMENO 8
bits, un int ALMENO di 16 e cosi' via.  Se il tuo codice assume che,
ad esempio, un intero abbia esattamente 32 bits (almeno cosi'
interpreto la tua uscita), bene, e' nato male e morira' prima o poi in
un core dump.


[...]
Quando rispondi lascia sempre la frase del genere "Pinco Pallino
wrote:".
Grazie
-- 
Marco Barisione (ICQ 84277092)

 Molto più comodo avere un char già di 16 bit, no?
wchar_t è "un char a 16 bit". O meglio è un char il cui numero di bit
dipende dalla piattaforma. Ed è stato inventato per poter gestire
codifiche con più di 8 bit per gli alfabeti (Unicode è solo un esempio).


 Un programmatore qualificato non avrebbe mai posto una simile domanda.
Forse. Ma sicuramente non avrebbe dato una simile risposta.


 un core dump.
Mumble. Maurizio, sei sicuro? Oggi come oggi praticamente tutte le
piattaforme hanno il char di 8 bit e penso che sarà così per sempre. Ma
un sistema potrebbe avere architettura a 7 bit e supportare egregiamente
una codifica (magari la stessa ASCII) sufficiente a sviluppare codice
C++. In questo sistema un char avrebbe 7 bit e gli altri interi
avrebbero multipli di 7 bit. Non credo che lo standard obblighi ad avere
char di 8.
Allo stesso modo oggi come oggi non ha assolutamente senso dato che
praticamente tutti i sistemi sono forniti di ALU con almeno 16 bit. Ma
un vecchio sistema o un sistema con una ALU che gestisce un solo byte
potrebbe benissimo avere int di dimensione uguale a char. Tecnicamente
credo proprio che un int di 8 bit non sarebbe per nulla fuori standard.


 C++.
Si. Ma C99 non è legato, per il momento, a C++. Anche se è plausibile
che verranno introdotti in una versione successiva dello standard ed è
anche plausibile che verranno adottati da alcuni compilatori C++ 64 bit,
questi nomi, pur se originati in unao standard (C99 appunto) non
dovranno essere considerati standard per il C++ (almeno fino al momento
in cui non verrà revisionato tale standard, e la revisione non avrà
nulla a che vedere, tempisticamente parlando, con il supporto delle
architetture a 64 bit). Pertanto resta vero che sui compilatori C++ per
architetture a 64 bit l'accesso ad alcune dimensioni per gli interi non
sarà consentito in maniera portabile (nota: la relativa aritmetica lo
sarà tramite l'uso dei bitfield).


 char di 8.
Penso che prima o poi si arrivera' ad avere char di 16 bit come scelta
piu' diffusa. Tra parentesi quello che dici e' ragionevole finche'
restiamo su piattaforme tradizionali: tempo fa qualcono scrisse su
c.l.c++.m a proposito di un processore con char = short = int = long a
32 bit.
Ciao,
Nicola

 wrote in message
news:3BDD456E...@divalsim.it...

La mia critica a Maurizio era sul fatto che char debba avere almeno 8
bit per lo standard. Io credo che anche una piattaforma con char a 7 bit
sarebbe standard. Che poi di piattaforme con word a 7 bit non se ne
sviluppino più è un altro discorso.
Riguardo al passaggio di char da 8 a 16 o più bit, non saprei. Tutto è
possibile. Ma stando allo standard bisognerebbe avere indirizzamento
minimo di 16 bit perchè il char sia di 16 bit. In pratica una
piattaforma (non parlo solo del linguaggio ma della piattaforma HW
stessa) non potrebbe gestire l'ASCII e le codifiche a 8 bit. Possibile?
Si certo. Probabile? IMO non per un bel pezzo!


 che la risposta sia no.
Ho lavorato su un DSP dove char, short, int e long erano tutti di 32
bits...


 Mumble. Maurizio, sei sicuro?
Beh, dipende :-)  Come ho gia' detto in un altro post, ci sono DSP che
hanno char, short, int e long tutti di 32 bits.  Quello che puo' far
morire il programma non e' tanto la lunghezza delle parole, quanto
l'usare le parole a sproposito: come la malsana abitudine, che trovo in
qualche programma non scritto da me e che mi tocca guardare, di mettere
in un int dei pointers; o quella di creare delle maschere tipo
0xFF000000 presupponendo che una parola sia di 32 bits; o cosi' via.


 sarebbe standard.
Ah, _adesso_ ho capito!  Si, e' possibilissimo; il vincolo e' che
un char possa contenere "... any member of the basic execution
character set."


 bits...
Giusto. Chissà perchè mi vengono sempre in mente i sistemi embedded e
gli HW particolari come esempio di architetture con 7 o 9 bit ma non
come esempi di architetture il cui indirizzamento è limitato. In un DSP
ha perfettamente senso che la dimensione della word sia una e unica e
che questa sia (al giorno d'oggi) anche di grandi dimensioni.


 character set."
Esatto. Quella è in generale l'unica limitazione verso il basso alle
dimensioni di un char. E direi che 6 o 7 bit potrebbero bastare in
alcuni environment particolari.
Il vero dubbio che ho sempre avuto stà nell'equivalenza fra char e byte
che per lo standard sono la stessa cosa.
Sono d'accordo che char deve poter contenere un carattere. Ma allora ci
dovrebbe essere byte come unità di indirizzamento. La differenza non
esiste nei sistemi general purpose e probabilmente neppure nella maggior
parte dei sistemi specifici. Ma esistono (o almeno sono esistite)
architetture in cui l'unità di indirizzamento era il bit. E certo 1 bit
non basta a contenere nessun "basic execution character set". Ma lo
standard non dice questo quindi...


 0xFF000000 presupponendo che una parola sia di 32 bits; o cosi' via.
Già. Capita anche a me di farlo. Ma solo per programmini usa e getta che
so per certo gireranno su una ed una sola piattaforma.


sarebbe standard.
Per BS no, ma forse in un post di qualche mese fa era gią venuto fuori
che lo standard non lo dice e quindi BS avrebbe sbagliato.
-- 
                    Marco Barisione (ICQ 84277092)
Se sei interessato alla creazione di it.comp.lang (per i linguaggi di
programmazione senza un gruppo apposito e per i confronti fra i
linguaggi) partecipa alla discussione sul manifesto su it.news.gruppi.

 obblighi ad avere char di 8.
B.S. riporta le stesse limitazioni indicate da Maurizio per le 
dimensioni minime dei tipi predefinite. Per quel che riguarda lo std, 
una volta su una ml c'e' stata una discussione di questo tipo: alla 
fine un partecipante che poteva consultarlo disse che non c'era un 
paragrafo che indicasse quelle dimensionie esplicitamente, ma che si ci 
poteva arrivare combinando una serie di vincoli "minori" sparsi qua e 
la in tutto il documento, tra cui la sottosezione dedicata al C.
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 la in tutto il documento, tra cui la sottosezione dedicata al C.
Io ho lo standard e non mi pare che si possa ricavare che il char debba
essere si almeno 8 bit. Però non ho lo standard del C. In ogni caso non
vedo come i riferimenti dello standard del C++ a quello del C possano
implicare una cosa del genere. Per di più credo che neppure lo standard
C (anche se non l'ho) richieda byte di 8 bit. Mi piacerebbe sapere
esattamente quali paragrafi (e cosa dicono nel caso dello standard C)
implicherebbero una cosa simile.


essere si almeno 8 bit.
Da dove l'ha preso BS allora? Lo ha inventato?



Non credo che un DSP faccia molto testo....
E' una 'piattaforma' piuttosto dedicata.
Ciao  Manlio Perillo

 stessa) non potrebbe gestire l'ASCII e le codifiche a 8 bit.
E' proprio per questo che auspicavo un indirizzamento a 16 bit.
Si manderebbe a quel paese tutta la babele dei vari set di caratteri
basati sull' ASCII.
Ciao  Manlio Perillo


???
(P.S. non ho mai detto di essere un programmatore qualificato)
Ciao  Manlio Perillo


Scusate se mi intrometto, ma forse il mio umile parere potrebbe
risultare di qualche aiuto.
Ricordo tempo fa di aver contribuito io stesso ad una discussione
del genere, sempre su questo NG,
propugnando la tesi secondo la quale un char e'
almeno di 8 bit, uno short almeno 16 e un long almeno 32.
La prima volta ho visto queste "garanzie" in:
"B. Stroustrup - C++: linguaggio, libreria standard, principi
 di programmazione, 3.rd edition - Addison Wesley", §4.6
(per l'edizione italiana siamo a pag. 86).
Qualcuno (non ricordo bene chi), non contento di questa fonte,
ando' a spulciare lo standard del C++, e vi trovo' da qualche
parte che la lunghezza di un char in C++ (definita dal template
numeric_limits<char>) equivale alla costante CHAR_BIT del C,
che sembra essere specificata (in una clausola a quanto pare 
appena visibile in una nota a pie' di pagina)
come ALMENO di 8 bit.
Detto questo, io nel frattempo credo a Stroustrup ;-)
Ciao a tutti!!
Domenico Barra
-- 
Domenico Barra, Brainbench C++ Master
ba...@programmazione.it
dob...@iol.it
domb...@studenti.unina.it

Detto questo, io nel frattempo credo a Stroustrup ;-)
Anch'io, del resto lui é "il creatore del C++".
Il Ghenio
-----
These are my parting words to you:
those who give up are doomed!
-----

 E' una 'piattaforma' piuttosto dedicata.
Sbagli Manlio. Il motivo alla base del non definire a priori le
dimensioni dei tipi non ha come scopo il permettere implementazioni
C/C++ per piattaforme a 16/32/64/128 bit nell'ambito mainstream ma
proprio la possibilità di usare il C/C++ (per ora si preferisce ancora
il C, ma la cosa sta gradualmente cambiando) per i sistemi embedded, per
i sistemi dedicati e per gli HW particolari. Fra cui la programmazione
dei DSP o di processori "speciali".
Tanto è vero che scrivere un compilatore C/C++ che supporti
efficacemente una piattaforma superdedicata è persino più facile che
scriverne uno che supporti una piattaforma mainstrem di nuova
concezione. Pensa solo al fatto che il C/C++ prevede quattro diverse
dimensioni per i tipi interi (il C99 ne prevede 5, se non sbaglio)
mentre un processore mainstream a 128 bit ne manipola facilmente da 5 a
7 diverse (via HW gestisce 8/16/32/64/128 con risultati di
moltiplicazione e divisione a 256, gestisce facilmente 256 bit con un
piccolo aiuto e probabilmente gestisce anche "oggetti" numerici da 80
bit).


 Detto questo, io nel frattempo credo a Stroustrup ;-)
Io no. A meno che non salti fuori che le garanzie suddette siano
specificate nello standard del C non sono vere. Lo standard del C++ non
le garantisce.
Domanda: lo standard C è ancora in vendita o si trova solo lo standard
C99 ?


 Da dove l'ha preso BS allora? Lo ha inventato?
Io ho quello del C++ non quello del C. E quello del C++ fa riferimento a
quello del C in alcune cose (in teoria solo per le librerie, non per il
linguaggio, ma come deducibile nell'altro subthread questo a volte può
influire sul linguaggio in maniera inaspettata).
Però resta ancora da vedere dove ha trovato le garanzie di short >= 16 e
long >= 32.


 C99 ?
Uhm... credo che si trovi, anche se non sono riuscito ancora a capire come 
ottenerne una copia (d'altra parte dovrebbe costare poco, visto che ormai è 
superata)
Ciao
Domenico
-- 
Domenico Barra
Brainbench C++ Master
ba...@programmazione.it
domb...@studenti.unina.it

 superata)
Mi piacerebbe sapere quanto costa e come ottenerla (anche in
elettronico, come per lo standard C++).


Non credo. Inoltre lo standard ...
No no... scusa :-) Con "Syntax Error" intendevo solo dire
che non ho ben compreso la costruzione della frase
(era un modo per scherzare ;-)
Cmq credo che chiedere a BS, oppure postare su comp.lang.c++
o su comp.lang.c++.moderated non sia una cattiva idea.
Non lo faccio stasera perche' ho sonno, ma domani vedro' che
posso fare.
Ciao a tutti :-)
Domenico
-- 
Domenico Barra, Brainbench C++ Master
ba...@programmazione.it
domb...@studenti.unina.it

dello standard.
Tratto dall'ANSI C Rationale:
"All objects in C must be representable as a contiguous
sequence of bytes, each of which is AT LEAST 8 bits wide."
-- 
The Follet

C (anche se non l'ho) richieda byte di 8 bit.
Vedi altro mio messaggio: lo standard del C richiede che un
byte sia ALMENO di 8 bit.
-- 
The Follet

 e long >= 32.
 
io non ho lo standard del C, pero' il K&R versione ANSI riporta la 
frase: "Ogni compilatore e' libero di scegliere la dimensione 
appropriata all'hardware, e deve sottostare alla restrizione secondo la 
quale short e int devono essere almeno 16 bit e long almeno 32 bit".
Ovviamente questa non e' una risposta definitiva, ma mi sembrerebbe 
alquanto strabiliante che Stroustrup, Kernighan e Ritchie avessero 
preso tutti una cantonata!
cmq il dubbio rimane...


 sequence of bytes, each of which is AT LEAST 8 bits wide."
Mi ero convinto che nello standard C ci fosse la limitazione in basso
alla dimensione di char a 8 bit. Ma non ancora del fatto che short debba
essere almeno 16 o long almeno 32.


 cmq il dubbio rimane...
Già. E' meno dubbio ma non è ancora certezza (per quella ci vorrebbe il
testo dello standard C).


 wrote in message
news:3be649e2...@news.tin.it...

Vedi mia risposta all'altro messaggio. Sai qualche cosa sui limiti dello
standard C (non C99) per short e long?


quale short e int devono essere almeno 16 bit e long almeno 32 bit".
il K&R riporta a pag 349 appendice B11,  i valori minimi consentiti
delle costanti tra cui:
       CHAR_BIT       8

 non rompere codice che assumesse int di 32 bit.
per stare tranquilli basta che uno si scrive un header con...
#if (sizeof(int)==32)
#define INT32  int
#endif
o non si può fare?



Non si può fare. Ne abbiamo discusso una decina di giorni fa in un thread
intitolato "nuovo operatore: valueof".
Max

 thread intitolato "nuovo operatore: valueof".
e, in ogni caso, non sarebbe corretto. sizeof restituisce un valore in 
multipli di sizeof(char), ma non c'e' modo di sapere quanti bit ha un 
char.



E per i floating-point?
Se int ha 32 bit suppongo che anche float sarà di 32 bit.
Quindi double ha 64 bit e long double 128 bit?
Ciao  Manlio Perillo

 Quindi double ha 64 bit e long double 128 bit?
Per gcc su alpha un float ha 32 bits, un double 64 bits ed un long
double ancora di 64 bits...
-- 
Maurizio Loreti                         
http://www.pd.infn.it/~loreti/mlo.html
Univ. of Padova, Dept. of Physics - Padova, Italy            
lor...@pd.infn.it