Newsgroup: it.comp.lang.c++
Titolo: Tipo int e tipo char....

Ciao,
quando un tipo di dato e' integer vuol dire che l'informazione binaria
memorizzata viene assunta con il valore DECIMALE corrispondente mentre se il
dato e' di tipo CHAR viene assunta secondo il valore ASCII corrispondente?
Scusate la banalita' ( x voi ) della domanda (:-)))
-----
ciao, grenzo

 dato e' di tipo CHAR viene assunta secondo il valore ASCII corrispondente?
No, la rappresentazione non cambia tra int e char. Solo il numero di
bytes utilizzati.
EMG

 ha scritto nel messaggio
news:3AE3F02A...@flashnet.it...

?
se, poniamo, avessi un int a 2 byte con il valore binario 00000000.00110000
( 48 DEC ) cosa leggo il decimale 48 o il corrispondente codice ASCII 0 (
zero) ?
------
ciao e grazie della risposta.
------
grenzo

 zero) ?
Sono la *stessa* cosa. Casomai sono le funzioni di output che si
comportano in modo differente a seconda del tipo di dato.
Ciao,
Nicola

 zero) ?
Vuoi dire, se facessi una cosa del genere?
int n = 48;
char c = n;
Avrei il valore 48 sia in n che in c. Il tipo char è, infatti, un
normale tipo numerico. E' solo quando vado ad utilizzare l'oggetto
std::cout per stamparlo (o std::cin per leggerlo) che quest'ultimo (o
meglio l'operator <<) lo converte nel carattere corrispondente al codice
numerico (nel nostro caso '0').
EMG
PS. Il codice ASCII 0 non c'entra niente.

 ha scritto nel messaggio
news:3AE424F1...@divalsim.it...

Quindi la definizione del tipo di dato serve esclusivamente ai fini
dell'output ?
-------
ciao e grazie della risposta
-------
grenzo


Il decimale 48 ('0') e il codice ASCII 0 *non* sono la stessa cosa!
EMG

 Il decimale 48 ('0') e il codice ASCII 0 *non* sono la stessa cosa!
Oops! :-)
Ciao,
Nicola

 ha scritto nel messaggio
news:3AE43974...@flashnet.it...

Scusa forse mi sono spiegato male (:-)))
volevo dire:
il numero in base 2: 00110000 corrisponde a 48 in base 10?
e il numero in base 2:  00110000 corrisponde al n.0 ( zero) se interpretato
tramite la tabella di conversione ASCII ?
---------
ciao grenzo

 Oops! :-)
Finalmente ti ho potuto correggere in qualcosa. :-)))
EMG

 tramite la tabella di conversione ASCII ?
Si, precisando meglio, 00110000 in base 2 corrisponde al carattere ASCII
'0' in quanto quest'ultimo ha codice 48. Chiaro?
EMG


Chiarissimo, grazie
quello che non ho capito e' perche' vengono dichiarati i tipi CHAR in quanto
se la conversione dell' informazione binario \ codice ASCII viene fatta
dalla funzioni di lettura e scrittura che sanno gia' di dover 'trattare' il
dato in quel modo  e' inutile una ulteriore dichiarazione di tipo.
Non e' che i dati di tipo CHAR devono essere scritti e letti comunque
tramite la codifica ASCII indipendentemente dalle funzioni di lettura e
scrittura verso il video o la stampante?
Scusa la confusione......
--------
ciao grenzo
p.s. in pratica non ho capito il motivo 'base' della necessita' di
tipizzazione dei dati che non sia la dimensione di occupazione in memoria.
Non so se te ne eri accorto...(:-))))

 Non so se te ne eri accorto...(:-))))
Il punto fondamentale e' poter distinguere il modo di operare sui dati
ed in questo i meccanismi di input/output sono solo l'esempio piu'
evidente. Se io ho:
v = 48;
std::cout << v;
mi aspetto in uscita 48 o 0 ?
Cosi' come se ho in memoria: 01000001 01000010 01000011 00000000
E' il numero 
3292676864
 o la stringa "ABC" (terminata con uno zero) ?
Ciao,
Nicola

 Non so se te ne eri accorto...(:-))))
Il tipo char serve principalmente a rappresentare l'oggetto piu' piccolo, ovvero
un byte o un carattere ASCII appunto, e fa quindi da base per le stringhe. In C
(e anche in C++) una stringa e' rappresentata come un vettore di char (in C++
esiste anche, ed e' meglio usare, la classe string delle STL). In alcuni vecchi
linguaggi (tipo il Basic originale) non esiste un tipo che rappresenta
direttamente il char, ma esiste un tipo predefinito che rappresenta una stringa.
Nei linguaggi in cui e' presente un tipo char questo puo' essere considerato
come tipo non aritmetico (salvo la possibilità di ottenere il valore ASCII in
forma di intero) o come tipo aritmetico (come nel caso del C/C++). In questo
secondo caso char non e' altro che un intero piu' corto. E ha come scopo, oltre
alla rappresentazione efficiente delle stringhe, permettere una piu' efficiente
gestione della memoria o del formato binario di una struttura (o record). La
maggioe parte degli HW permettono la manipolazione diretta di byte come valori
aritmetici, ma senza guadagno in efficienza rispetto ad int.
I tipi short del C/C++ hanno come scopo permettere una piu' efficiente gestione
della memoria o del formato binario di una struttura (o record). Alcuni HW
permettono la manipolazione diretta di questi tipi, ma senza guadagno in
efficienza rispetto ad int.
I tipi int sono gli interi nativi della piattaforma.
I tipi long sono degli interi che supportano magnitudini maggiori (o uguali) a
int ma non sono (di solito) supportati direttamente dal'HW e, se lo sono,
presentano, in genere, una minore efficienza.
--
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

 tipizzazione dei dati che non sia la dimensione di occupazione in memoria.
Esattamente: la diversa occupazione di memoria è proprio il motivo per
cui esistono diversi tipi di dati numerici.
EMG

particolarità è che è il più piccolo.
Per conformità si dovrebbe chiamare <byte>, secondo me...
Luc.

 -------
Neanche perche' con i cast puoi anche cambiare tutte le carte in tavola.
Potresti ad esempio definire il seguente int:
int a = 48;
e fare:
cout << (char)a;
e trovarti sullo schermo uno ZERO!
Allora come stanno in realta' le cose?
Semplice, in base al tipo di informazione che devi contenere usi il
"CONTENITORE" piu' opportuno.
Se devi "GESTIRE" (non necessariamente produrre a video) dei caratteri ecco
che il CONTENITORE piu' opportuno sono i "char". Ma anche le temperature di
un termometro da ascella "pezzata" potrebbero trovare posto in un "char". Se
invece devi gestire delle informazioni con un range ipotetico da 1000 a 5000
ecco che, viste le dimensioni, vanno meglio gli "short".
Tieni comunque presente che in ogni caso il tipo piu' ottimizzato e' sempre
"int" e di conseguenza, a meno che tu non stia programmando PLC o macchine
con risorse fortemente limitate, puoi tranquillamente utilizzare "int" in
quasi tutte le situazioni anche in quella che ti ho fatto esempio sopra.
In sostanza cio' che contraddistinque i tipi fondamentali interi tra di loro
e' proprio la dimensione, cioe' il numero di bit, cioe' la loro capacita' di
rappresentazione in termini di range numerici. In secondo luogo, ma questo
e' mooooooooolto platform-dependent, le ottimizzazioni a cui possono essere
soggetti.
Spero di averti chiarito.
Ciao.
- /\nDRe/\ -

Luc <TOGL...@katamail.com-TOGLI> wrote in message
qb6bet8ltkrog45s4...@4ax.com...

Non sarebbe formalmente corretto!
Infatti il "char" nasce come tipo per rappresentare l'insieme di base dei
caratteri.
Se tu rimani nel contesto dei PC IBM con il char non riesci infatti a
rappresentare tutti i 256 valori che starebbero in un byte mentre riesci
benissimo a rappresentare i codici ASCII da 0 a 127 che sono quelli
internazionali.
Quindi se devi rappresentare 256 valori diversi (anche perche' sappiamo
benissimo che in 8 bit ci stanno in realta' tutti) devi pero' utilizzare
"unsigned char".
Questo vuol dire che sui PC IBM puoi permetterti di fare:
typedef unsigned char byte;
... ma su altre macchine/piattaforme o implementazioni di compilatori e'
tutto da dimostrare.
ciao!
- /\nDRe/\ -

 e trovarti sullo schermo uno ZERO!
da cio' evinco che cout << tratta l'informazione a seconda del tipo che essa
possiede.
Quindi definire una variabile di tipo CHAR significa voler interpretare
l'informazione che essa contiene ESCLUSIVAMENTE mediante la codifica ASCII
( indipendentemente dalla quantita' di bit utilizzati,  il fatto che
corrisponda ad un byte e' dovuto al motivo che 256 valori  rappresentano
esattamente i codici ASCII standard + gli estesi) mentre una variabile di
tipo int ( indipendentemente dalla dimensione ) contiene una informazione
che deve essere interpretata ESCLUSIVAMENTE per il valore numerico che essa
contiene.
Da cio' intendo che i tipi non sono stati creati per distinguere la
dimensione ma, appunto, il TIPO di informazione che contengono. Poi sono
stati seguiti dai tipi che a parita' di TIPO di informazione tengono conto
anche della quantita' di bit utilizzati.
O no?
Ciao e grazie della risposta
--------
grenzo

 Nicola
giusto?
-------
ciao e grazie,
grenzo

 dimensione ma, appunto, il TIPO di informazione che contengono.
Possiamo meglio dire che esistono due distinzioni:
la prima puramente formale:
abbiamo i char -> char, signed char, unsigned char -> dedicati ai caratteri
abbiamo gli int -> s/u short, s/u int, s/u long -> dedicati ai numeri
la seconda fisica:
dove tutti possono contenere interi, vettori di bit, valori logici ma con
capacita' diverse!


 dimensione
I tipi numerici sono stati creati proprio per quello.
Ora cerca di non confonderti ancora.
EMG

 trattandosi di un blocco di 4 byte suppongo sia di tipo int ( o long int )
E come fai a supporlo senza conoscere le intenzioni di chi ha riempito
quella memoria? E' come quando apri un file senza conoscerne il formato.
EMG

un byte o un carattere ASCII appunto, e fa quindi da base per le stringhe. In C
a voler essere pignoli, il tipo char deve essere grande abbastanza per
poter contenere un carattere dell'insieme di caratteri usati dal
sistema (chi ha detto ASCII? c'è stato un altro thread al riguardo) e
deve essere grande almeno 8 bit.
Poi una domanda: lo standard definisce "byte" la dimensione di un char
oppure esso continua ad avere il normale significato di 8 bit?
Anto
--
Antonio Cuni, 18 anni, studente
Brainbench Certification: 
Master C++: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
http://www.brainbench.com/transcript.jsp?pid=1301688

Per conformità si dovrebbe chiamare <byte>, secondo me...
secondo me non sarebbe male avere due tipi distinti, in cui sia chiaro
una volta per tutte se si usa un carattere o un numero.


 una volta per tutte se si usa un carattere o un numero.
non e' cosi' complesso da realizzare, antonio.

tutto da dimostrare.
Credo che valga per tutti la stessa rappresentazione.
Lo standard assicura che un char e' lungo SEMPRE 1 byte.
E se il byte, su ogni macchina, e' senza segno, allora il typedef del
byte va bene su qualsiasi piattaforma.

registrarci altre info!
mi sento di dover fare una precisazione: char č il tipo numerico che
occupa meno memoria, ma non per questo crediate che esso sia anche il
piů veloce, anzi! Visto che al giorno d'oggi abbiamo a disposizione
vagonate di RAM, il mio consiglio č di usare quasi sempre int, che č
garantito (credo) essere il tipo di dato piů veloce sulla CPU per la
quale il programma č compilato.


 Sbagliato. Come ho già detto, char *è* un tipo numerico.
Ok e visto che e' un 'normale' tipo numerico ( quindi un int a 8 bit ) come
fa il cout << a 'trattarlo' come un codice ASCII e non come un numero? se
dentro c'e' scritto 48 dovrebbe restituire 48 e non 0......
Scusa l'insistenza, sono sicuro che tu abbia ragione, ma sono agli inizi e
non vorrei trascinarmi dei dubbi ' esistenziali ' per troppo tempo.........

 dentro c'e' scritto 48 dovrebbe restituire 48 e non 0......
Perché esiste un overload dell'operator << che ha come parametro un tipo
char e che ne stampa a video il carattere corrispondente invece che il
numero.
EMG

 ha scritto nel messaggio
news:3AE7BFD8...@flashnet.it...

Ok, tutto chiaro.
Ringrazio molto te e tutti quelli della lista che mi hanno risposto.
-----
ciao, grenzo

 quale il programma è compilato.
Esatto. In termini di pura velocità di calcolo il char e' garantito essere *non
piu' veloce* di int. E lo stesso vale per short e long. In altre parole int e'
il tipo piu' efficiente per il calcolo puro, per definizione. Che poi sulle
architetture moderne in realtà il tempo di esecuzione di una operazione intera
sia praticamente lo stesso per tutte le size e' un altro discorso. Cosi' come e'
un altro discorso il caso in cui devi processare una grande quantità di dati per
cui considerazioni di bus e cache possono rendere piu' veloce l'uso di short (o
char) invece che int. Ma non si tratta di velocità di calcolo, si tratta di
velocità di trasferimento dati. Ovvero di una considerazione legata alla
dimensione e alla posizione in memoria degli operandi.


 oppure esso continua ad avere il normale significato di 8 bit?
Per lo standard byte non e' definito come char ne viceversa. Pero' anche byte,
come char, e' definito in termini di "grande abbastanza da contenere i caratteri
del set usato dall'implementazione" nonche' unitariamente indirizzabile nonche'
avente tutte le combinazioni possibili di bit come valori validi.
Ergo di fatto sono la stessa cosa.


 una volta per tutte se si usa un carattere o un numero.
in realta' ci sono addirittura tre tipi distinti di carattere:
char, unsigned char e signed char.
Generalmente il primo si usa per i caratteri e gli altri due per i
numeri.
/fabio


 uscira' il valore numerico corrispondente e non i caratteri.
Neanche questo e' detto. dipende da come e' dichiarata la variabile che
si riferisce a quella zona. Se e' int e' il numero se e' char* e' la
stringa.
Ciao,
Nicola


Secondo lo standard il byte e' il piu' piccolo elemento di memoria
indirizzabile e deve essere grande abbastanza da poter contenere un
char.
Ciao,
Nicola

 byte va bene su qualsiasi piattaforma.
Non sono sicuro che lo standard dica a chiare lettere che un char e'
lungo esattamente un byte. Se ho capito bene un byte potrebbe contenere
bit in piu' della dimensione di un char, ma questi bit non sarebbero mai
utilizzati in un programma C++, a causa della convertibilita' dei tipi
in sequenze di char.
Ciao,
Nicola

 per i caratteri!
I tipi di dati non sono solo contenitori: determinano anche la semantica
dei dati che rappresentano, ovvero il loro significato e il modo di
utilizzarli.
Ciao,
Nicola

lungo esattamente un byte.
Fidati. Lo standard afferma che un char e' SEMPRE lungo 1 byte.
Poi, il byte puo' anche essere lungo piu' di 8 bit, ma la regola
sizeof( char ) = 1 non viene mai violata.


Per essere precisi lo standard dice (1.7 1):
A byte is at least large enough to contain any member of the basic
execution character set and is composed of a contiguous sequence of
bits, the number of which is implementation-defined.
e poi (3.9 1):
For character types, all bits of the object representation participate
in the value representation.
ed infine (5.3.3 1):
The sizeof operator yields the number of bytes in the object
representation of its operand. [...] sizeof(char), sizeof(signed char)
and sizeof(unsigned char) are 1;
In effetti hai ragione tu, ma ammetterai che giungere a questa
conclusione richiede un po' di studio :-)
Ciao,
Nicola

non e' cosi' complesso da realizzare, antonio.
non č neanche facilissimo: per come me lo ero immaginato era utile una
cosa del genere:
char per i caratteri
signed/unsigned byte per i numeri
Secondo me sarebbe anche auspicabile che essi fossero tipi distinti
(magari fornendo anche le conversioni implicite), quindi una typedef
non va bene. Si potrebbe creare una classe wrapper, ma come gestisci
signed/unsigned?
Una cosa a livello di standard sarebbe molto piů semplice.


 quale il programma č compilato.
Togli pure il credo! E' sempre il tipo piu' ottimizzato.
Il tuo consiglio e' corretto. Esistono pero' ancora alcune realta' aziendali
(leggi microcontrollori, plc, algoritmi ultra-verticali, ecc.) dove a volte
si cerca di fare economie di spazio e per questo un char, se sufficiente,
puo' sempre fare comodo. ;-)


 wrote in message
3ae6fefe...@news.libero.it...

Ci sono macchine come i vecchi Unisys 1100 in cui l'elemento di minori
dimensioni e' di 9 bit!
E' chiaro quindi che un
typedef unsigned char byte;
ci garantisce cmq gli 8 bit che vorremmo avere quando parliamo di byte (ed
e' per questo che molti, me compreso, lo usano), ma e' formalmente
scorretto, in quanto nei nostri codici potremmo utilizzare erroneamente il
bit in piu'.
Si tratta comunque di una disquisizione da tavolino ed e' probabilmente un
altro motivo per cui in fase di progettazione non e' stato scelto il nome di
"byte" ma quello di "char".


 Anto
questo e' proprio il comportamento di char, signed char e unsigned char,
(che sono tre tipi distinti)
nell'esempio che segue nessuno dei sei assegnamenti e' legale:
void f()
{
   char * cp = 0;
   signed char *scp = 0;
   unsigned char *ucp = 0;
   cp  = scp;
   cp  = ucp;
   scp = cp;
   scp = ucp;
   ucp = cp;
   ucp = scp;
}
(nota che invece, ad esempio, int e signed int sono equivalenti)

 Ergo di fatto sono la stessa cosa.
Leggi un altro pezzo della discussione a tal proposito.


tuo sistema sia in grado di indirizare in maniera distinta unitą piu' piccole.
Stroustrup, paragrafo 4.6:
"Inoltre č garantito che un char ha almeno 8 bit, uno short almeno 16
bit e un long almeno 32 bit"
D'altronde č anche logico: altrimenti anche una semplice definizione
char a = 100;
non sarebbe portabile, rischiando di andare in overflow.
Anto
PS non immagini quale sia la soddisfazione di corregerti, almeno una
volta :-)))))))


(che sono tre tipi distinti)
si questo lo sapevo. Ma secondo me sarebbe meglio chiamarli (un)signed
byte invece di (un)signed char, per chiarezza. E poi non credo che gli
assegnamenti che hai fatto tu siano errati: dovrebbero esserci delle
conversioni implicite.


 conversioni implicite.
No. Assegnava dei puntatori.


 "...Inoltre e' sicuro che un char possieda almeno 8 bit..."
Allora mi correggo: non sta scritto da nessuna parte nello standard che
definisce il linguaggio. Dubito che in merito il tuo testo ... faccia testo.


 volta :-)))))))
Se ritorni indietro di 3 mesi e rotti ti accorgi che anche io ho scritto
cavolate.
Comunque quella degli 8 bit io non la vedo nello standard. Posso sbagliarmi ma
fino a che mi indicate testi diversi dall'unico che conta ...


 wrote in message
news:3AE94089...@divalsim.it...

non sono d'accordo. Il fatto che il numero di byte e il numero di char debbano
coincidere si evince incrociando 5.3.3 sub 1 con 3.9 sub 4, ma questo non
significa che non ci possano essere dei bit nel byte che non sono usati
dall'implementazione. Nota che 3.9 sub 1 fa riferimento alla rappresentazione
che a sua volta e' definita in termini di sequenza di unsigned char in 3.9 sub
4. Ergo un byte di 10 bit e un char di 7 bit con 3 bit che non vengono mai usati
non viola nessuna norma, neppure 3.9 sub 1 dato che la rappresentazione non
comprende i byte ma i char stessi.
Comunque siamo effettivamente ai limiti del paranoico. La realtą e' che esistono
pochissime architetture in cui l'unitą indirizzabile e' inferiore agli 8 bit, e
si tratta di architatture che indirizzano un bit o 4 bit e pertanto
assolutamente incapaci di contenere un qualunque tipo di set di caratteri, ergo
si puo' tranquillamente presumere che tutte le implementazioni del C++ abbiano
char di almeno 8 bit. Notate pero' che esistono architetture in cui l'unitą
minima indirizzabile e' piu' grossa di 8 bit.


 wrote in message
news:3AE93962...@divalsim.it...

Esatto salve che la sequenza e' una sequenza di 'unsigned char' e non di 'char'.
Immaginate una ipotetica architettura dotata di bus dati a 10 bit e relativo
processore con registri a 10 bit. Immaginate una altrettanto ipotetica
implementazione (ovvero compilatore) che abbia come 'basic character set'
l'ASCII americano a 7 bit e che definisca un char di 7 bit. L'implementazione e'
legale. Il byte e' di 10 bit. Il char, l'unsigned char e il signed char avranno
tutti 7 bit.


comprende i byte ma i char stessi.
Nessuno sta negando questo.
Si stai affermando che la lunghezza di un char e' 1 byte su qualunque
piattaforma.

fino a che mi indicate testi diversi dall'unico che conta ...
a volte sono nascosti nei posti più impensabili dello standard; cmq mi
sembrerebbe alquanto strano se Stroustrup avesse scritto una cavolata.
Anto


 wrote in message
news:3aeae60...@news.libero.it...

La lunghezza di un char misurata in byte e' uno (e viceversa). Ma la lunghezza
di un char e quella di un byte misurate in bit possono essere diverse e non
hanno nessun legame con il famigerato, e in questo caso poco fatidico, numero 8.


hanno nessun legame con il famigerato, e in questo caso poco fatidico, numero 8.
Ripeto :
Nessuno ha mai messo in dubbio che la differenza tra il numero di bit
significativi per un byte e quelli significativi per un char possa
esistere.  Si discute se un char sia lungo o meno 1 byte.

 bit e un long almeno 32 bit"
non mi pare corretto! io so che un char ha almeno 8 bit, e che
sizeof( char) <= sizeof( short) <= sizeof( long)
e basta. Sbaglio?

"Simone Finotti" <x...@xxx.xx> wrote in message
news:JZDG6.15009$sb5.1...@news.infostrada.it...

A parte che un char potrebbe anche averne 7.
Non sbagli sul resto salvo che hai dimenticato di inserire l'int!


 Non sbagli sul resto salvo che hai dimenticato di inserire l'int!
mmmmhh... sapevo male allora! comunque int non l'avevo messo perchč
nel post a cui ho risposto non compariva! ;)

 ha scritto nel messaggio
news:3AE9353C...@divalsim.it...

Ok, Nicola
ho capito: la definizione del TIPO di variabile fa si' che il dato contenuto
venga 'trattato' in modo diverso dalle funzioni\operatori che lo gestiscono.
La dimensione assegnata al TIPO e' una conseguenza della necessita' di
contenere i valori necessari: CHAR e' a 8 bit perche' 8 bit sono sufficienti
a contenere 256 combinazioni e, quindi, i codici ASCII.
-------
ciao e grazie
grenzo

Non sbagli sul resto salvo che hai dimenticato di inserire l'int!
ma Stroustrup allora era ubriaco quando ha scritto il suo libro?


 a contenere 256 combinazioni e, quindi, i codici ASCII.
Esatto, salvo che la dimensione del tipo char dipende dalla piattaforma
specifica, cosi' come il fatto che il set di caratteri utilizzato sia
ASCII oppure un altro.
Ciao,
Nicola

 ma Stroustrup allora era ubriaco quando ha scritto il suo libro?
Non lo so. Ma  possono esserci vari casi, fra cui:
1) lo ha scritto prima che lo standard fosse finito.
2) di fatto NON esistono compilatori con char diverso da 8 bit, anche se non e'
vietato che esistano non ha molto senso farli.


 comprende i byte ma i char stessi.
Penso che sia un'ambiguita' involontaria, anche perche' 3.9 4 esprime la
rappresentazione in char, mentre 5.3.3 1 la esprime in byte. Provo a
chiedere agli esperti.
Ciao,
Nicola

 dimensioni e' di 9 bit!
A me sembrava di ricordare che il 1100/80 avesse word di 36 bit divisa
in byte di 6, ma sono passati tanti anni...
Ciao,
Nicola

vietato che esistano non ha molto senso farli.
Io veramente per lavoro ho fra le altre cose a che fare con
un compilatore C in cui il char e' di 16 bit.
Si tratta di un compilatore per un DSP della Texas in cui
l'accesso alla memoria e' organizzato in unita' da 16 bit.
Per come e' fatto l'hardware l'unico modo di usare solo
8 bit e' buttarne via 8 facendo una AND.
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

 8 bit e' buttarne via 8 facendo una AND.
Ops! Intendevo dire compilatori mainstream. Per Windows o per Linux o altri OS
mainstream. Se si va nel mondo dei sistemi embedded ... ci sono anche sistemi
che indirizzano un singolo bit!!



Ne ha scritte, ne ha scritte (anche lui come tutti noi)....
Ciao
Manlio Perillo

Ne ha scritte, ne ha scritte (anche lui come tutti noi)....
tornando sull'argomento del minimo di 8 bit ai char, ecco cosa ha
scritto un partecipante alla ML C++ Warriors (non mi assumo alcuna
responsabilità, visto che non ho la standard a disposizione):
Si, finalmente ho trovato il riferimento nello standard: non basta un
documento per arrivarci
ma me ne sono serviti!
<FORWARD>
Nel capitolo "18.2.1 Numeric Limits" dello standard C++ viene
introdotta la classe template
numeric_limits che, come riportato  in una minuscola nota, deve
fornire dei valori equivalenti
a CHAR_MIN,SHRT_MIN,... definiti in <climits>, corrispondente
all'header C standard
<limits.h>.
A questo punto bisogna chiudere lo standard C++ per aprire quello C
(io ho solo un draft
C90) e scoprire che i valori minimi accettati dallo standard per le
varie macro *_MIN, e
*_MAX sono tali da richiedere minimo 8 bits per i char, 16 per gli
int/short e 32 per i long.
</FORWARD>
Ciao Anto
--
Antonio Cuni, 19 anni, studente
