Newsgroup: it.comp.programmare
Titolo: Cosa significa KB, MB, GB ???

O meglio, cosa significa K, M, G?
Effettivamente c'è chi afferma che K = 10^3, M = 10^6, G = 10^9, quindi
1 KB = 10^3 Bytes
1 MB = 10^6 Bytes
1 GB = 10^9 Bytes
e c'è chi afferma che trattandosi di Bytes (quindi in questo caso
"eccezionale"):
1 KB = 2^10
1 MB = 2^20
1 GB = 2^30
Voi come la pensate?
Kiuhnm

 Voi come la pensate?
Questo è lo standard per l'informatica [1] (dovuto al fatto che i computer 
usano le potenze di 2) e, giusto per complicare un po' le cose, Kbit, Mbit 
e Gbit seguono le regole normali (10^qualcosa).
In realtà da quello che so gli standard dicono che si dovrebbero utilizzare 
le potenze in base 10; un altro standard (o candidato ad esserlo?) dice che 
i MB in potenza di due andrebbero indicati come MiB, i GB GiB, i KB KiB 
(non ho mai visto però nessuno che lo utilizzasse).
[1] Tranne chi vende hard-disk che usa le potenze in base 10 per far 
sembrare i dischi rigidi più grossi.
-- 
Marco Barisione (ICQ 84277092)

 (non ho mai visto però nessuno che lo utilizzasse).
Anche io sapevo che andavano indicati con MiB, GiB, ecc... (mebibyte,
gibibyte, ecc...) pero` ls per esempio li scrive solo con una lettera (M, G,
K)
Maurizio

 utilizzasse).
MiB? Mai sentito...se non al cinema...non deve aver preso molto piede :-)
Kiuhnm

 O meglio, cosa significa K, M, G?
Mah, effettivamente la definizione può risultare equivoca...... credo non
esista uno standard o una regolamentazione vera e propria a riguardo....
Saluti
--
NinjaCross
 
www.ninjacross.it
Sconnetti il chip isolineare per contattarmi
ninjacross_CH...@yahoo.it

 Forse volevi dire che si lavora in BASE 2.
???
--------------------------------
Inviato via 
http://usenet.libero.it

 velocita' e' molto inferiore rispetto a 80 KB.
Ti sbagli anche qui: la velocità del datalink si misura esclusivamente sul
carico di dati del payload (e quindi 8 bit), i dati di controllo non vengono
conteggiati. Il motivo per cui la banda passante percepita è inferiore
dipende dal fatto che ci sono vari livelli nel protocollo TCP/IP, ergo prima
di arrivare al datalink ogni livello aggiunge il suo header, che occupa
spazio.
*** Azimuth ***

 I processori della famiglia Intel 68000
Motorola volevi dire... ;) 
-- 
Luc.

 Motorola volevi dire... ;)
Obviously....
*** Azimuth ***

 carico di dati del payload (e quindi 8 bit)
Errore, il calcolo avviene su 9 bit.
it.tlc.telefonia, per maggiori informazioni.


 ogni livello aggiunge il suo header, che occupa spazio.
Sarà che ho avuto *culo*, ma io (con virgiliotin) scarico a 80 KB tondi :-)
Kiuhnm

 it.tlc.telefonia, per maggiori informazioni.
Ti consiglio caldamente di chiedere in quell'area, così capirai dove sbagli.
*** Azimuth ***

 Ti consiglio caldamente di chiedere in quell'area, cosě capirai dove
sbagli.
Sei tu che sbagli, sei tu che devi informarti, sei tu che devi imparare.
Non staro' qui a sprecare acqua e sapone per lavar la testa all'asino.


 Non staro' qui a sprecare acqua e sapone per lavar la testa all'asino.
Perfetto: per lavarti la testa puoi andare anche dal barbiere sotto casa.
*** Azimuth ***

 Parole da 6 e 7 bit, parole da 1 a 64 bit..
No, studia e impara, come gia' detto, si parla di ****BYTE**** non parole:
"byte
<unit> /bi:t/ (B) A component in the machine data hierarchy usually larger
than a bit and smaller than a word; now most often eight bits and the
smallest addressable unit of storage. A byte typically holds one character.
A byte may be 9 bits on 36-bit computers. Some older architectures used
"byte" for quantities of 6 or 7 bits, and the PDP-10 and IBM 7030 supported
"bytes" that were actually bit-fields of 1 to 36 (or 64) bits".
[definizione di "byte" da parte del FOLDOC].


 cui fondamenta ignori totalmente.
Avevo fatto bene a plonkarti, mi ripropongo:
<plonk>
*** Azimuth ***

 <plonk>
ROTFL ;) poverino ;)
Di fronte all'evidenza dei fatti, non ti rimane altro che questo ;)
Plonka pure, ignora pure chi contesta quanto affermi, e' il modo migliore
per convincersi di aver ragione. Provo una pena sincera per te ;)


 Sarà che ho avuto *culo*, ma io (con virgiliotin) scarico a 80 KB tondi
:-)
Evidentemente la tua matematica ha delle falle gravi: 80 KByte = 80 * 1024
Byte = 81920 byte. Questo vuol dire che se anche dividessi 640 Kb per 8 e
non per 9 (inteso 1 Kb = 1000 bit come si conviene e non 1024, come nel caso
dei KByte), avresti: 640000 / 8 = 80000 bit, che e' una velocita' fisica
inferiore a quella che riporti. Quindi, o il tuo modem ha i superpoteri o,
molto piu' plausibilmente, hai detto l'ennesima stupidata ;)


 Forse volevi dire che si lavora in BASE 2.
Non essere pignolo, stavo per uscire di casa e ho scritto in fretta... :-)


 esista uno standard o una regolamentazione vera e propria a riguardo....
Ciao, mi ero posto anche io questo problema e ho scoperto che tutto
questo è dovuto ad una contraddizione che è sempre esistita e che lo
IEC ha cercato di risolvere nel dicembre del '98 derivando dal sistema
metrico internazionale (SI) i prefissi per i multipli binari da
utilizzare nei campi dell' elaborazione e tramissione dati.
Senza andare troppo per le lunghe, la situazione è questa: per gli
ingegneri delle telecomunicazioni e i produttori di dischi fissi 1MB è
1.000.000B invece per i produttori di RAM è 1.048.576, valore che
coincide anche per alcuni progettisti di reti ( 1MBs=1.048.576bit/s );
come se non bastassero già due misure, il megabyte dei floppy da 3.5
pollici vale 1024000B.
Lo standard in realtà c'è perchè lo IEEE ha deciso di usare gli
standard internazionali a meno che non sia specificato, caso per caso,
che si sta lavorando su potenze di due, in questo caso, per l'appunto,
è:
1 kibibit scritto 1 Kibit = 2^10 bit = 1024bit
1 kilobit scritto 1 kbit = 10^3 bit = 1000 bit
1 mebybyte scritto 1 mIb = 2^20 B = 1048576bit 
1 megabyte scritto 1 MB = 10^6 B = 1000000B
Ho anche verificato che Windows non cita il SI invece, almeno per
alcuni comandi distribuiti nei SO GNU sono previste entrambe le
situazioni.
p.es
. su RedHat Linux, nel pacchetto fileutils c'e' il comando da
shell du che totalizza l'occupazione su disco di uno o più file e tra
le opzioni vi sono:
       -H, --si
              likewise, but use powers of 1000 not 1024
       -k, --kilobytes
              like --block-size=1024
       -m, --megabytes
              like --block-size=1048576
Non ho ancora visto usate le nuove diciture e nonostante sia
ampiamente open-mind mi sembrano veramente ridicole : ( ( ( ...sembra
quasi che l'abbiano fatto apposta...
Ciao!!
Francesco

 velocita' e' molto inferiore rispetto a 80 KB.
ma la misura è presa sul router o da un programma? comprende le
informazioni per l'incapsulamento?
Ciao,
Francesco

 informazioni per l'incapsulamento?
Le misure le ho lette da software (non ho neanche un router!) [per
intenderci Flashget, GetRight, ecc...].
Quando mi connetto mi segnala 832 Kbps, ma in realtà vado a 640 Kbps tondi
tondi (oscillo tra i 75 e gli 85 e in media scarico a 80 KBps).
Kiuhnm

 quasi che l'abbiano fatto apposta...
Il produttore di Man In Black non sporgerà denuncia???
Kiuhnm

 tondi (oscillo tra i 75 e gli 85 e in media scarico a 80 KBps).
Cazzata. Come gia' detto, 640 Kbps non puo' darti 80 KBps.


 è la parola dell'elaboratore. Il byte ha 8 bit, sempre.
   Stronzate su stronzate, eh?
 
http://www.dictionary.com/search?q=byte
 
http://www.tuxedo.org/~esr/jargon/html/entry/byte.html
	...
-- 
Alla prossima,
Marco


Quindi byte e word sono praticamente la stessa cosa, visto che sono entrambe
sequenze di bit.
Le definizioni sono tutte in contraddizione quindi non le prenderei in
considerazione.
Per esempio la "word" viene definita come:
"insieme di bit che costituiscono la più piccola unità di memoria
indirizzabile".
Ma nei processori Intel le word valgono 16 bit e la ppudmi è il byte!
Diciamo che oggi quando non si specifica nulla e si dice che un variabile è
lunga 10 byte si intende 80 bit.
Purtroppo noto sempre di più come l'Informatica non sia una "scienza molto
scientifica" sotto l'aspetto della nomenclatura.
Quello che voglio dire è che stabilite delle regole qualcuno può costruire
un processore che non le rispetti ed ecco che la regola è andata a farsi
friggere...
Kiuhnm

 	
http://www.tuxedo.org/~esr/jargon/html/entry/byte.html
Si, ma c'č anche, ad esempio:
http://whatis.techtarget.com/definition/0,,sid9_gci211721,00.html
La veritą č vera quando si propongono TUTTI i punti di vista, non solo 
quelli 'favorevoli'.
-- 
Luc.

 quelli 'favorevoli'.
??? non si tratta di "punti di vista", e' cosi', punto e basta.
Quelli che io e Marco abbiamo citato non sono "opinioni favorevoli", sono i
significati del termine "byte".


 scientifica" sotto l'aspetto della nomenclatura.
Sei tu che sei ignorante, e' molto diverso.


 scientifica" sotto l'aspetto della nomenclatura.
Più che altro, non è una scienza ma è una tecnica.
Ciao.
*** Azimuth ***

 come unità di misura (perché misura, appunto, sempre e comunque 8 bit), la
Questo, come tutto il resto di cio' che affermi, solitamente, e'
notoriamente falso.
Ti ho gia' dimostrato che la definizione di byte = 8 bit e' vera nella
maggior parte dei casi, non *sempre e comunque*.


 quelli 'favorevoli'.
   La veritia` e` vera se si conosce l'inglese, quando si cita un 
documento in inglese.
-- 
Alla prossima,
Marco

 Il produttore di Man In Black non sporgerà denuncia???
.... ahahah!! però c'ho messo un pò per capirla.
Mi sono tolto uno sfizio nell'approfondire questa definizione non
tanto per fare la punta allo s*****o ( ci pensano già in molti,
intendo fuori dal NG ) ma per interesse personale, comunque ti basta
fare un salto su un motore di ricerca e trovare tutte le informazioni
che ti servono, e ridondanti, copia e incollate tra una miriade di
siti e post su altri ng e mailing list in altre lingue di gente che si
era già posta la stessa domanda.
Tra le tante ho trovato che alla pagina
http://physics.nist.gov/cuu/Units/binary.html
 ci sono precisi
riferimenti bibliografici e storici.
...e comunque lo Zingarelli 2002 della Zanichelli non è aggiornato:
riporta 1MB = 1 048 576 B!!!
Saluti

 riporta 1MB = 1 048 576 B!!!
Capirai...
Kiuhnm

 molto piu' plausibilmente, hai detto l'ennesima stupidata ;)
O forse viene riportata la quantita' di dati "utili" e non quella 
"trasmessa"; lo so mi spiego male, ma se i dati inviati sono compressi i 
software a volte riportano la quantita' di dati trasmessi dopo averli 
decompressi....
My 0.02

 *** Azimuth ***
ciao

 dopo averli decompressi....
Laforgia l'ho plonkato, ma tramite te posso rispondergli:
guarda che il modem ADSL scarica massimo a 8 Mbps quindi gli unici che
limitano la banda sono i provider! (coglione!).
Per rispondere a te invece ti posso garantire che ottengo gli stessi
risultati anche scaricando file ZIP o BZIP2 (ancora più compressi), quindi è
difficile che possano essere ulteriormente compressi.
Kiuhnm

 letta ed interpretata bene da qualsiasi combinazione software/hardware
Dipende sempre da cosa vuoi fare.
Kiuhnm

 allora puoi tranquillamente usare long, short, ecc...
Niente affatto. Li puoi usare *tranquillamente* se non fai riferimento
esplicito alle loro lunghezze in bit.


 un'altra piattaforma, ma anche apportare delle modifiche.
in teoria, no. Deve bastare modificare un paio di header (in teoria 
nemmeno questi, perchè quelli standard del compilatore dovrebbero già 
occuparsi di tutto), e ricompilare
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.20. C, C++ and ASM developers
                              and beta testers are welcome!

 limitano la banda sono i provider! (coglione!).
Qui se c'e' un coglione sei tu: impara a contare, imbecille.


 occuparsi di tutto), e ricompilare
E' IMPOSSIBILE!
Inoltre la totale portabilità del codice scritto in un linguaggio di alto
livello, implica minore efficienza (vedi Virtual Machine, Emulatori, ecc...)
Kiuhnm

 livello, implica minore efficienza (vedi Virtual Machine, Emulatori,
ecc...)
Mma quando la finira' di dire certe scemenze ? per quanto dovremo sorbirci
questo "cazzaro" ?


 Emulatori, ecc...)
la totale portabilità di codice scritto in un linguaggio di alto 
livello è LO scopo di usare un linguaggio di alto livello


 livello è LO scopo di usare un linguaggio di alto livello
E allora com'è possibile che un programma di basso/medio livello come il C
riesca a essere contemporaneamente portabile ed efficiente?
I linguaggi ad alto livello allora a che cosa servono se hanno LO scopo di
essere portabili?
Kiuhnm

 essere portabili?
Non sono questi i vantaggi dei linguaggi ad alto livello. E` l'astrazione
che cambia. In C devi descrivere quello che fai in ogni minimo particolare.
I problemi ci sono quando per fare delle particolari cose sei costretto ad
usare funzionalita` non standard legate alla piattaforma che usi. In molti
linguaggi ad alto livello ad esempio l'interfaccia grafica e` possibile
farla con funzioni standard, quindi il programma rimane portabile, in C
no.
Maurizio

 standard, quindi il programma rimane portabile, in C no.
Non si era capito che la mia affermazione era ironica? (quando mai
confermerei una cosa detta da Maya :-) )
Kiuhnm

 l'esperienza venga tutta e soltanto dai libri...
...
Maurizio

 il problema.
Il problema sta nel fatto che non posso usare gli int a 128 bit nemmeno se
ho una CPU in grado di farlo.
E se lo faccio il codice diventa automaticamente *non portabile*.
Non ti sembra un problema?
Kiuhnm

 Ed è riconosciuto a livello mondiale?
   No, l'ARPA e` solo un gruppetto di amici che si riunisce l'ultimo 
venerdi` di ogni mese per una pizza al locale all'angolo...
-- 
Alla prossima,
Marco


Bravo, ma io ho scritto "riconosciuto" e non "conosciuto". Non mi pare
proprio che i programmi scritti per architetture IA-32 utilizzino il Big
Endian di regola....
Kiuhnm

, Kiuhnm ha scritto:

Certo che e` un problema, ma relativo ad un caso particolare. Non puoi
neanche usare socket, thread, ecc... con la sola libreria standard, se li
usi il tuo programma non e` portabile.
Il fatto e` che pero` spesso molti programmatori si affidano ad estensioni
dei compilatori anche quando non ce n'e` bisogno, ignorando il fatto di
poter mantenere gran parte di un software portabile su altre piattaforme
ed isolando le poche parti che invece necessitano di modifiche.
Maurizio

 dimensioni.
assolutamente falso. Lo standard non parla di alcuna "modalita`", e ogni 
compilatore puo` assegnare le dimensioni che vuole ai tipi built-in, a 
patto che segua determinate regole:
1 = sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
1<= sizeof(bool) <= sizeof(long) [ovviamente questa vale solo per il C++]
sizeof(char) <= sizeof(wchar_t) <= sizeof(long)
sizeof(float) <= sizeof(double) <= sizeof(long double)
sizeof(N) = sizeof(signed N) = sizeof(unsigned N)
un char ha almeno 8 bit, uno short almeno 16 bit e un long almeno 32 bit.
Queste sono le uniche specifiche sulla dimensione dei tipi: dimmi tu dove 
si fa riferimento alla modalita` (che per inciso ha senso solo se 
parliamo di x86).
In ogni caso se anche le dimensioni dei tipi fossero le stesse la 
rappresentazione binaria della struct del post precedente sarebbe 
probabilmente diversa cambiando compilatore, a causa del diverso 
padding.
ciao Anto
-- 
"Computer science is not about computers any more than astronomy
is about telescopes." -- EW Dijkstra

 necessitano di modifiche.
Questo è vero, comunque pensa che spesso ho dovuto perfino aggiungere asm
inline (tanto il prg. era specifico per Windows su processori IA-32)
Kiuhnm

 padding.
Diverso padding?
Tutti i programmatori tenderebbero ad utilizzare lo stesso padding e
comunque di solito si usa una direttiva (per es. pack(1)) e si aggiungono i
pad manualmente.
Kiuhnm

 pad manualmente.
E perché non lasci fare al compilatore invece?
-- 
Marco Barisione (ICQ 84277092)

 E perché non lasci fare al compilatore invece?
Perchè a volte non voglio il padding oppure in asm ho usato un padding
diverso e quindi gli allineamenti non coincidono...comunque ho notato che
molti compilatori usano lo stesso padding. Certamente non è la regola.
Con le mie affermazioni volevo soltanto dire che spesso la pratica è diversa
dalla teoria (è un po' come seguire regole non scritte).
Kiuhnm

 bit tipo quello dello SNES.
Kiuhnm, hanno fatto uno Unix per MSX (CPU Z80A, 8 bit). Incluso TCP/IP. 
Che richiede certe larghezze per gli interi (16 e 32 bit) e una certa 
endianness (big)


 se hanno LO scopo di essere portabili?
a scrivere programmi... senza preoccuparsi dell'architettura? poi non 
so, fai tu


 nemmeno se ho una CPU in grado di farlo.
non so se sei scemo o se lo fai apposta. intptr_t, uintptr_t


 non so se sei scemo o se lo fai apposta. intptr_t, uintptr_t
Mi chiedo la stessa cosa di te, ma in proposito non ho dubbi.
Ti sei chiesta perchè si chiamano [u]int*ptr*_t?
Significa che devono essere sufficientemente grandi per contenere un
puntatore.
Secondo te un processore in grado di fare calcoli con int a 128 bit deve
avere per forza uno spazio d'indirizzamento di 2^128 unità???
Kiuhnm

 una certa endianness (big)
Non centra niente! Ignorante come al solito...
Con un qualsiasi linguaggio e CPU si posso gestire interi di un numero
arbitrario di bit. Se si vuole si posso gestire anche int da 1153 bit.
Ma come ti ho già detto mi aspettano cose più importanti.
Kiuhnm

 so, fai tu
Ma allora non hai capito niente?
Kiuhnm

 Arridaje...mi spieghi che cosa risolve questo?????????
con un #ifdef e un #error il tuo problema è risolto. Ecco cosa risolve


 Mai sentito parlare di "bug del millennio"?
il problema non è mai esistito. Se fosse esistito davvero, si sarebbe 
verificato molto prima. Viene lasciato come esercizio al lettore lo 
scoprire perchè. Comunque, mai sentito parlare di IPv6? del 7 febbraio 
del 2106? certo che servono interi di certe dimensioni - quando si deve 
interagire con cose su cui non si ha il controllo, come il tempo che 
passa, il numero di utenti di una tecnologia a larghissima diffusione. 
Questo intendevo con il "perchè". Se il "perchè" è misurare qualcosa in 
continua e possibilmente infinita crescita, OK. Se il "perchè" è avere 
numeri più grossi di quelli del tuo vicino, esistono già librerie per 
lavorare su numeri di dimensioni arbitrarie: sono più portabili, e si 
può tranquillamente assumere che con ordini di grandezza minori e 
uguali a quelli che tratta la CPU usino la soluzione ottimale (le 
istruzioni native), e soluzioni efficienti per ordini di grandezza di 
poco superiori. Senza andare tanto oltre, il typedef serve anche a 
questo - off_t può essere 32 bit su una certa piattaforma e 64 bit su 
una certa altra, per questo per gli offset all'interno di un file non 
si usa un uintX_t di qualche tipo ma un alias


 unità???
è una buona approssimazione della realtà. Anzi, spesso succede l'esatto 
opposto


 Qui se c'e' un coglione sei tu: impara a contare, imbecille.
Per riconoscere un coglione ce ne vuole un altro, ma nel tuo caso, caro 
Laforgia, basti tu.
Federico G.

 se ho una CPU in grado di farlo.
ma che cazzo stai dicendo?!
E` *garantito* che il tipo "int" corrisponda alla parola del processore: 
se hai una cpu a 128 bit gli int saranno a 128 bit.


 processore: se hai una cpu a 128 bit gli int saranno a 128 bit.
Non hai seguito per niente il discorso: si parla di portabilità (a dispetto
dell'oggetto).
Scrivendo 'int' il codice non sarà più portabile e comunque si può
riformulare la domanda nel seg. modo:
"Come faccio a usare un int a 128 bit su una CPU a 256 bit?"
Oppure
"Come faccio a usare un int a 128 bit su una CPU a 32 bit che supporta
operazioni con interi di 128 bit?"
Kiuhnm

 ha scritto nel messaggio
news:mh93qa...@anto.cuni.lan...

Dipende sempre dal compilatore.
Con il Turbo C sotto DOS l'int comunque era a 16 bit nonostante lavorassi su
un 486 che a rigor di memoria aveva la WORD a 32 bit.
Martino.

 ed interpretata bene da qualsiasi combinazione software/hardware
Non è vero.
*** Azimuth ***

 indirizzi *hardware* a 8 bit - quando si dice la lungimiranza)
Non è esattamente questo il problema: non sono i 32 bit ad essere
penalizzanti ma la loro suddivisione in sole due componenti (NET + HOST) con
4 tipologie di rete (A,B,C,D) e la loro incauta allocazione. Tra l'altro,
l'unico motivo per cui si è adottato l'MSB è solo ed esclusivamente perché
le prime implementazioni dello stack TCP/IP sono state fatte su macchine con
processori MSB.
---
Comunque, cara Maya, non ti smentisci mai.
*** Azimuth ***

 essere completamente portabili.
Non sarei così drastico: se ti limiti ad un array di char (per rappresentare
qualsiasi tipo), hai la sicurezza di essere portabile. Ad esempio se fai
typedef char INT1024[ 1024 >> 3 ];
e poi la usi come fosse un tipo primitivo, avrai la sicurezza che
INT1024 somma( const INT1024& _a, const  INT1024& _b )
lavorerà esattamente con interi da 1024 bit, dovunque.
Tra l'altro, se usi il little endian, AL CONTRARIO DI QUANTO AFFERMATO, puoi
essere molto più portabile: infatti supponi di dover sommare due numeri a
1024 bit: se hai fatto una routine che somma due char, hai automaticamente
quella che somma a 1024 semplicemente iterando con il carry. Puoi far questo
con l'MSB? No, a meno che non conosci in anticipo la lunghezza dei dati da
trattare!
*** Azimuth ***

 COMPILATORE C.
   Hai provato a modificare la tua definizione in
	struct record {
	  int  campo0;
	  char campo1[80];
	  char campo2[90];
	};
e provare a scriverla su file?
<code>
	#include <stdio.h>
	struct record {
	  int  campo0;
	  char campo1[80];
	  char campo2[90];
	} rec={
	  42,
	  "1234567890123456789012345678901234567890"
	  "1234567890123456789012345678901234567890",
	  "123456789012345678901234567890123456789012345"
	  "678901234567890123456789012345678901234567890"
	};
	int
	main(void)
	{
	  FILE *out=fopen("azimuth.dat","wb");	
	  fwrite(&rec,sizeof(struct record),1,out);
	  fclose(out);
	  return 0;
	}
</code>
   A me viene un file (azimuth.dat) di centosettantasei byte, non 
dovrebbero essere (sizeof(struct record)) centosettantaquattro? Non sono 
forse questi i problemi di condivisione di cui parlava David?
-- 
Alla prossima,
Marco

 e provare a scriverla su file?
Mi sembra di averti già scritto che:
1. ci sono problemi di padding (i compilatori allineano le strutture dati in
maniera che sia più veloce accedervi anche se occupano di più);
2. ci sono problemi dato che lo standard C e C++ non prevede una dimensione
esatta degli int.
Per il problema 1 si può ovviare eliminando il padding (come opzione di
linea o direttiva #pragma pack() o altro).
Per il problema 2 ho suggerito l'adozione di utilizzare strutture dati
basate sul char.
Entrambi i problemi non sono legati alla lunghezza del byte bensì al fatto
che il C ed il C++ non vincolano i loro tipi primitivi.
La tua struttura la ridefinirei così:
/* SE NON HAI BISOGNO DI ESSERE PORTABILE TRA COMPILATORI C */
#pragma pack(push)
#pragma pack(1)
struct record {
   int campo0;
   char campo1[80];
   char campo2[90];
};
#pragma pack(pop)
/* SE *HAI* BISOGNO DI ESSERE PORTABILE TRA COMPILATORI C */
typedef char INT[ 4 ];
#pragma pack(push)
#pragma pack(1)
struct record {
  INT campo0;
   char campo1[80];
   char campo2[90];
};
#pragma pack(pop)
Ciao.
*** Azimuth ***

 Laforgia, basti tu.
Chissa' perche', ma ho come il sospetto che Azimuth e Federico G. siano la
stessa persona.
La loro idiozia e' identica.
--------------------------------
Inviato via 
http://usenet.libero.it

 linea o direttiva #pragma pack() o altro).
Le direttive pragma, per definizione, non sono portabili.
Continua pure a dire cazzate.


 basate sul char.
meglio usare i tipi standard(come ricordava Maya in qualche post piu su):
int16_t
int32_t
e cosi via.....
ciao

 int32_t
Non esiste int1024_t (o, in generale, int[n]_t).
Ciao!
*** Azimuth ***

 lavorerà esattamente con interi da 1024 bit, dovunque.
No. Non ovunque. sizeof( char ) == 1, pero` segue le convenzioni dello
standard, parte del quale era stato postato in questo ng e dove non veniva
specificato il numero di bit del char. Anche se fosse vero che byte == 8bit,
questo non e` vero nello standard C.
Per il discorso sulla portabilita`, nel libro che ti era stato consigliato
da Lanugo qualche settimana fa, c'e` un intero capitolo. Io non so chi sei te
quindi permettimi di dirti che mi fido molto meno di te piuttosto che di
Kernighan e Pike:
"Il punto chiave dell'approccio byte per byte e` che risolve il problema,
senza #ifdef, per qualsiasi macchina con byte a 8 bit."
(Programmazione nella pratica, pag.231)
che e` piuttosto in contrasto con la tua affermazione di pochi post fa:
"1 byte == 8 bit. DOVUNQUE"
Maurizio

 #pragma pack(pop)
Questo non è portabile.


 Non esiste int1024_t (o, in generale, int[n]_t).
giusto anche qui, ma i casi sono 2:
o ti serve un buffer di 1024 byte e quindi ricadi in
char buffer[1024] che ti dara' sempre e cmq sizeof()==1024
oppure ti serve un int di 1024byte al che spero tu usi una libreria 
bignum gia' esistente, che non conosco ma spero abbiano delle routine 
del tipo toBuffer() fromBuffer() per serializzare il numerone
in ogni caso sai sempre quanti byte vai a scrivere su file

 (Programmazione nella pratica, pag.231)
... il punto chiave è che così:
1) aumenti la manutenzione del codice (più righe == più possibilità di
errori);
2) diminuisci l'efficienza (non puoi scrivere N strutture in con un solo
write o leggerne N con un solo read);
3) è ridondante, in quanto il byte ha 8 bit.
*** Azimuth ***

 in ogni caso sai sempre quanti byte vai a scrivere su file
Certo. Con un sizeof lo so sempre...
*** Azimuth ***

 Questo non è portabile.
Ok, fai un bell'#if...#endif e passa la paura.
Ciao.
*** Azimuth ***

 Modern architectures è la parola chiave.
Non lo e'. Tu hai confutato che possano esistere dei byte con un numero di
bit diverso da 8 e' molto diverso. Ora, al tuo solito, ti lanci in un
arrampicamento di specchi.


 Nello standard C il byte č di 8 bit
No, il char č di *almeno* 8 bit per il C.


 Nello standard C il byte č di 8 bit
Falso, lo dico io che devono consentire di inserire delle illustrazioni su
Usenet.
A quanto pare, le semplici parole (forse perche' in una lingua cosi' astrusa
come quella anglossassone ?) sono difficili da comprendere. Spero che nella
tua testolina sia chiaro il significato di "at least".


 3) è ridondante, in quanto il byte ha 8 bit.
altrimenti non lo scrivevano.
Maurizio

 typedef char INT1024[ 1024 >> 3 ];
questo funziona solo se il numero di bit di un char e` 8.
Ovviamente questo non e` garantito...
ciao Anto


 *almeno* di poter rappresentare i caratteri ASCII.
Non i caratteri ASCII ma quelli usati dalla macchina. Mi pare (potrei 
sbagliare) che lo standard richieda che il byte sia almeno di 8 bit, 
abbastanza grande per contenere il charset usato dalla macchina e che 
sizeof(char) == 1.


 conosci in anticipo la lunghezza dei dati da trattare!
Infatti l'MSB secondo me è scomodo...hai presente quando devi scrivere un
numero molto grande sul foglio e ti ritrovi a dover andare a capo perchè hai
lasciato troppo poco spazio? :-)
Kiuhnm

 supporta operazioni con interi di 128 bit?"
scrivere il programma in C++, definire i tipi e gli operatori per conto 
proprio. Aggiungere qualche #ifdef, mescolare con vigore, guarnire con 
una fettina di limone, servire freddo
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.20. C, C++ and ASM developers
                              and beta testers are welcome!

 Non esiste int1024_t (o, in generale, int[n]_t).
"[...]
7.8 Format conversion of integer types <inttypes.h>
The header <inttypes.h> includes the header <stdint.h> and extends it 
with additional facilities provided by hosted implementations. [...]"
Se esiste, è dichiarato qua dentro


 unità??? 
newsflash: qualcuno, lassù, ha pensato anche a te. intmax_t, uintmax_t. 
Divertiti


 lunghezza dei dati da trattare!
questione di direzione dello stack :-)


 Comunque, cara Maya, non ti smentisci mai.
ti amo anch'io, Azy


 ti amo anch'io, Azy
Smack.
*** Azimuth ***

 Ovviamente questo non e` garantito...
Tipo...? Mi fai un esempio di ambiente di sviluppo dove la dimensione in bit
di INT1024 č minore di 1024?
*** Azimuth ***

 non puoi sapere neanche di cosa parlano (ma solo immaginarlo).
Non ci vuole mica un super uomo (donna) per capire cosa dice un uomo
(donna).
Ciao.
*** Azimuth **

 lasciato troppo poco spazio? :-)
Sì, ho presente... :-)
*** Azimuth ***

 Sì, ho presente... :-)
:-)
Kiuhnm

 la CPU potrebbe eseguire somme tra int128_t, non supportati dallo
standard).
Perché, non posso fare un compilatore che effettui un loop unrolling di una
copia di 4 * N bytes, ad esempio, facendo una copia di N words a 32 bit?
Ciao!
*** Azimuth ***

 a 32 bit?
Questo non è considerato "loop unrolling" e comunque la copia è una cosa,
mentre l'operare sui tipi in un modo arbitrario è un'altra cosa.
E' facile trattare un caso particolare, ma il problema è che le operazioni
possibili sono infinite e stai programmando troppo a basso livello perchè il
compilatore sappia effettivamente che cosa stai facendo.
Kiuhnm

 compilatore sappia effettivamente che cosa stai facendo.
Potrei sfruttare qualche similitudine omomorfica? Ad esempio, se riesco a
ricondurre nella forma
FOR( i = 0; i < N; ++i )
    op( byte[ i ] ); // con effetti collaterali solo su byte[ i - 1],
yte[ i +1 ]
Posso riscrivere come
FOR( i = 0; i < N / y; ++i )
    op( x[ i ] )
Con y == sizeof( x ) ?
*** Azimuth ***

 Con y == sizeof( x ) ?
Finchč le espressioni sono cosě semplici, si puň fare, ma se il codice č piů
complesso e chiama funzioni, sottofunzioni, ecc... ricondursi a tale modello
richiede secoli (e poi non č detto che l'array venga scandito
sequenzialmente).
Kiuhnm

 Ecco, allora se non č meglio, perché adottarlo?
uno cattivo standard č meglio di niente standard e basta, come dice 
quel famoso. E comunque, nelle parole del gruppo Unicode, "endianness 
only matters during I/O"
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.20. C, C++ and ASM developers
                              and beta testers are welcome!

 only matters during I/O"
Non mi pare.
*** Azimuth ***

             of bytes, each of which is at least 8 bits wide.
appunto: i byte sono *almeno* 8 bit.
Il che mi pare ben diverso dal dire che sono *esattamente* 8 bit.
Anto
-- 
"Computer science is not about computers any more than astronomy
is about telescopes." -- EW Dijkstra