Newsgroup: it.comp.lang.c
Titolo: scrivere/leggere file composto

Ho la necessità di creare un file contenente header+contenuto.
L'header è una struttura contenente i 2 campi
char str[50];
int len;
il contenuto non è altro che una sequenza di caratteri di lunghezza non
prestabilita.
Per creare questo file io pensavo di usare la write per la scrittura della
struttura e poi continuare ad inserire i caratteri con la fputc...è una
soluzione valida?
Quando devo invece leggere l'header ed il contenuto è giusto fare:
FILE *f=fopen.....ecc
fread(f......ecc /* leggo l'header */
while(EOF!=(c=getc(f)) {
    /* leggo il contenuto */
}
???????? Ci sono soluzioni migliori?
Spero di essere stato chiaro...
Grazie
Bizio

Unica annotazione: si cerca sempre di non leggere/scrivere un byte alla
volta, ma di usare un buffer (lungo di solito multipli di 4096 bytes). In
questa maniera si va piů veloci (4096 bytes č di solito la dimensione di una
settore fisico dell'hd mi sembra... O per lo meno č la dimensione di una
pagina di memoria!). Chiaramente l'ultimo blocco non lo leggerai per intero
ma solo in parte... Quindi in pratica controlli sempre se hai ricevuto 4096
caratteri o meno.
Inoltre, anche se il SO la pagina l'ha in ogni caso letta in memoria,
chiamate alle funzioni del SO (che sono implicite quando fai una
fgetc/fputc/fread/fwrite) richiedono del tempo.
--- bye

 }
Lo schema (abbozzato in questo modo) mi sembra corretto.

 pagina di memoria!).
Non su tutti i sistemi.
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

Vero che non è vero per tutti i sistemi... Cmq l'hard disk non legge un
settore alla volta... Se no l'opzione del bios IDE Multiple Sector Mode per
cosa servirebbe? :-)
Ero un po' stanco. Il suggerimento cmq regge lo stesso, anche se per
motivazioni leggermente diverse. In pratica andrebbe sostituito con: leggere
un numero di bytes pari a una potenza del due, con 4096 che è un buon numero
per un'architettura Intel e probabilmente PowerPC (mi sembra che le pagine
abbiano le stesse dimensioni). Aumentare le dimensioni del buffer, se si
dispone di abbastanza memoria, male non fa (e a meno che non si parli di
sistemi embedded anche 8-16kb di  memoria non sono nulla). Male che vada non
aumenta le prestazioni. Diminuire le dimensioni del buffer male fa. :-)
--- bye

 aumenta le prestazioni. Diminuire le dimensioni del buffer male fa. :-)
Non  e`  del  tutto  vero,  ed  e`  un  tipico  caso  di  ottimizzazione
precoce.  Prima di tutto devi tenere conto che l'OS effettua una propria
bufferizzazione, del  tutto indipendente da quella  fatta dalla libreria
C. Poi c'e`  la bufferizzazione  fatta dalla libreria  stessa. Un buffer
troppo grosso,  poi, puo`  causare un  trashing della  cache, diminuendo
*drastricamente* le prestazioni del  programma [1]. Senza contare che il
fattore limitante  e` la  velocita` dell'HD, non  quella dell'algoritmo.
Se, usando un profiler, si dovesse scroprire che le prestazioni del quel
codice sono inaccettabilmente  basse, allora (e sono in  questo caso) si
provvedera` ad  ottimizzare usando buffer di  dimensione adeguata oppure
implementando una propria politica di read-ahead.
L'unica ottimizzazione "preemptive" che si  puo` fare e` usare getc/putc
(se  possibile -  ovviamente) per  evitare l'overhead  delle chiamate  a
funzione.
Luca
[1] Su x86  il metodo piu` veloce  per copiare un file e`  usare un loop
con un buffer di 4096 byte, in modo che buffer e loop stiano nella cache
L1. Subito dopo viene mmap(). Ma qui` siamo OT :)
-- 
Home: 
http://kronoz.cjb.net
"Ci sono le balle , le megaballe e le statistiche".
 Mark Twain