Newsgroup: it.comp.lang.c++
Titolo: Come creare questo tipo di dati?

Come posso istanziare un tipo di dati "cifra" ottimizzato in modo che si
inserisca un numero da 0 a 9 utilizzando solo il numero strettamente
necessario di 4 bit, se i tipi built-in sono minimo di 1 byte (tipo char)?
é possibile o mi devo adattare a questo spreco di memoria?
Per favore rispondete anche a 
gio...@tiscalinet.it

 é possibile o mi devo adattare a questo spreco di memoria?
No, non devi adattarti, ma certamente devi scrivere un po' di piů.
Se vuopi gestirti tu la "compattazione" di pacchetti di cifre tramite
operatori sui bit o altro, sei libero di farlo, solamente che č una via piů
difficile.
Potrebbe esserti utile guardare la definizione di struct di bit, e
probabilmente anche la union per riuscire a salvare correttamente i
pacchetti.
--
Alessandro Monti

é possibile o mi devo adattare a questo spreco di memoria?
Non e` possibile allocare meno di un char (che di solito, ma non
necessariamente) occupa 1 byte. Solitamente la memoria e` indirizzabile
al piu` a livello di byte ed anche utilizzando i bit field non 
raggiungeresti a pine lo scopo (e oltretutto sarebbe poco performante).
Paolo
--------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
--------------------------------------------------

 raggiungeresti a pine lo scopo (e oltretutto sarebbe poco performante).
Giustissima l'osservazione sulle performance (per estrarre un sottoinsieme
dei bit di un byte -- e su moltissime CPU, anche solo un sottoinsieme dei
bit di una *parola*, che puo` essere tipicamente di 32 byte -- occorrono
operazioni-macchina supplementari).
Di conseguenza, l'impacchettamento con granularita` superiore al byte
interessa in pratica solo per enormi array -- MAI per variabili scalari, ne`
per array di dimensione piccola-media.  Nel caso di array enormi, se il
risparmio di memoria si traduce in una riduzione del working set del
programma (set di pagine di memoria virtuale attivamente accedute), le
prestazioni possono essere recuperate (i trade-off spazio/tempo non sono
mai banali in presenza di memorie virtuali, e magari di cache -- l'unica e`
*misurare* le prestazioni nei vari casi!).
Un array enorme dovra` probabilmente avere dimensione variabile a
runtime (e` improbabile, anche se certo non impossibile, che si debba
dimensionare a compile-time un array di "molti milioni di cifre" con un
numero preciso e noto a priori di cifre).  Da questo punto di vista,
l'ideale sembra definire un tipo "cifra" e specializzare std::vector<cifra>
(implementandolo con uno std::vector<unsigned char>, realizzando
un iterator come pair (std::vector<unsigned char>::iterator, mask),
eccetera).  Tuttavia, sono anche possibli altre situazioni, tipicamente
ad esempio quelle in cui gli array di molti milioni di cifre vanno usati
come *NUMERI* (nel qual caso interessera` implementare l'aritmetica
"Binary-Coded Decimal"), ovvero altre in cui gli array non sono in
modo diretto array di cifre bensi` array di *pacchetti* di un numero
fisso di cifre.  Bisogna completare l'analisi ("perche` voglio avere degli
array di molti milioni di cifre, che cosa ci faro`", ecc) prima di potere
delineare un decente progetto, e ovviamente anche prima di pensare
ai dettagli d'implementazione (situazione tutt'altro che rara!-).
Alex

per array di dimensione piccola-media.
[omissis]
aggiungerei che la cosa e` giustificata anche dall'attuale costo delle
memorie. Un tempo per acquistare 4 MB di ram per il mio 386
spesi ben 300Klire, oggi acquisti la ram un tot al kilo.
E` presumibile un tale andamento anche per memorie piu`
performanti della ram di sistema di un pc.
Anche quando bisogna lavorare con molte variabili "piccole" poi,
di solito si ricorre ad altre vie, tipo calcolo parallelo su piu` byte
alla volta (architetture SIMD), proprio per riuscire ad avere
performance maggiori, lavorando su parole di lunghezza
superiore al byte.


 particolare non e` il mio campo d'azione.
Esistono (o esistevano -- questione, ancora, di definizioni) simili
architetture, ma il compilatore C per esse e` comunque tenuto a
mascherarle al programmatore, eseguendo qualsivoglia mirabilie
di mask e shift occorra per presentare come "indirizzabile" una
entita` pari alla dimensione del carattere ("byte" nel senso del
linguaggio C, e, d'altra parte, anche C++).
Alex

"byte = 8 bit", OK.  Ma questa definizione non e` nello Standard C++
Appunto... dal tuo post mi pareva di aver capito (erroneamente) che lo
standard definisse il byte in termini di bit anzicche` in termini di
char...


 char...
Buffo, perche` dicevo esattamente il contrario: cioe`, che non si puo`
dire "un char non e` detto che occupi un byte", proprio perche` il
byte e` *definito* come il sizeof di un char (nello standard C, e ricordo
che lo standard C++ ingloba quello C "per riferimento").
Alex

dire "un char non e` detto che occupi un byte",
Il byte era in quel contesto inteso come 8bit. Se non erro lo standard
indica cio` che un char deve poter rappresentare, non su quanti bit
essere rappresentato, in questo senso lo standard mi pare ponga vincoli
del tipo sizeof(int)<=sizeof(long int).
Mi sa che gira e rigira stiamo dicendo la stessa cosa e non ci capiamo!
