Newsgroup: it.comp.lang.c++
Titolo: file di grandi dimensioni

Salve a tutti,
avrei bisogno di un consiglio,
ho la necessità di creare un archivio molto grande, probabilmente di
alcuni Gb,
questo file verrà gestito con una classe particolare visto che fstream
non lo permette,
pensavo di spostare il cursore di scrittura/lettura attraverso
seekp(0xFFFFFFFF,ios::cur) portandomi così alla posizione
desiderata, fin qui è corretto il metodo?
I dati dell'archivio sono elementi ordinati, questo comporta per ogni
elemento inserito, l'aggiornamento di tutte le posizioni
successive al nuovo elemento, per questo pensavo di utilizzare
vaschette parzialmente riempite, in maniera di aggiornare piccoli
settori dell'archivio, potrebbe andare o ci sono soluzioni
alternative?
grazie anticipatamente.

No, stai scrivendo/leggendo/spostando troppa roba su disco. Se ogni "record"
è grande, (diciamo >= 64 bytes) allora probabilmente ti conviene scriverlo
"come viene viene", poi creare un indice del file (in memoria) (ti servono 4
bytes per ogni record... Se i record sono >= 64 bytes si parla di 1/16 delle
dimensioni, che inizia a essere una quantità accettabile) e poi riscriverlo
una singola volta sfruttando l'indice.
Occhio che le funzioni del C++ credo funzionino solo su files fino a 2 o 4
gb (non so se sono signed o unsigned). Per files più grandi non ci sono
soluzioni standard.
--- bye

 soluzioni standard.
Preciso: credo che lo standard non specifichi qual è il tipo di dato "vero"
da usare per l'offset (proprio per questo viene usato un typedef che è
nascosto sotto un paio di strati di classi derivate). Però ho dato
un'occhiata... Con il VC++.NET sotto Win32 viene usato un long (che è un
intero a 32 bits con segno), sotto Win64 viene usato un int64 (sempre con
segno). E per le dimensioni del file vengono usati rispettivamente un int e
un int64. Quindi non conterei troppo di poter gestire files più grandi di 2
gb.
--- bye

 gb.
pienamente d'accordo, non voglio costringere nessuno alla soluzione di
questo piccolo problema,
ma per essere più dettagliati, l'archivio deve gestire miliardi di
elementi da 5 byte e la memoria verrebbe caricata inutilmente anche
con l'incizzazione a 1/16,
ogni consiglio è buono ;)
grazie anticipatamente

 con l'incizzazione a 1/16,
Nel tuo caso l'indicizzazione sarebbe quasi 1 a 1. Anzi, probabilmente
sarebbe anche peggio (il puntatore dovrebbe essere a 64 bits, cioč 8 bytes).
Dati i prerequisiti del tuo lavoro non ti resta che affidarti alle API
native del SO (sia sotto Windows che sotto Linux ci sono API per files a 64
bits). Per l'ordinamento l'algoritmo migliore in questi casi mi sembra sia
il merge sort (vado a memoria). Occhio che certi tipi di partizione (hint:
FAT32!) non permettono files sopra il paio di gb.
Oppure, se vuoi continuare ad usare il C/C++ standard puoi creare piů di un
file. Ogni file da diciamo 64 mb (cosě ci sta tutto in memoria) e,
conoscendo la distribuzione statistica dei dati, aggiungi i nuovi dati a un
file o all'altro.
La domanda fondamentale č: tu parti da un archivio ordinato E ci aggiungi
dati, o parti con tutti i dati e non ci farai mai aggiornamenti?
--- bye

Sto cercano di pensare ad un file che permetta un salvataggio che non
limiti troppo la dimensione,
questo tipo di file servirebbe per l'archivio statico di oggetti e per
gli archivi indicizzati ordinati.
Gli archivi ordinati adoperano indici da 5 byte per descrivere
posizioni nel file archivio oggetti,
5 byte garantiscono dimensioni superiori ai 1099 Gb,
ogni archivio ordinato descrive oggetti di un tipo specifico,
sinceramente non sň se la strada č la migliore, ma considerando
l'ordinamento indicizzato non vedo alternative all'utilizzo di
vaschette da 327.675 byte pari a 65535 indici da 5 byte,
la scelta delle vaschette parzilmente occupate, sembra interessante
perchč permette aggiornamenti "discretamente veloci" quando si deve
inserire un oggetto nel mezzo, tutto ha un limite, quando si
riempiranno serve distribuirle per liberarle parzialmente...
č un vero peccato, dopo aver spulciato i vecchi post, speravo ancora
ci fosse una soluzione per contenere tutto in un file, ma visti gli
ultimi aggiornamenti torneremo su piů file, preferirei non soffocare
l'implementazione ad un SO specifico, tutto sommato non č poi cosě
drammatico, basta considerare questo enorme file come una cartella, 
specializzare la "cartella" come un file ;)
ps: archivio statico di oggetti, perchč una volta inserito ci cade
addosso la carogna che non lo molla e non ne esce piů, questo verrebbe
gestito con un flag che nell'eliminazione garantisce la trasparenza
nell'archivio... ti pensi riscrivere Gb di dati per un pistola di
oggetto ?_^?
ti ringrazio per l'attenzione e i consigli ;)

Solo pensare il tutto mi fa venire un mal di testa terribile. Come pensi di
gestire lo splittamento delle vaschette e dei files? (se una vaschetta si
riempe, come fai a splittarla?)
Come fai a sapere qual è la vaschetta giusta da usare? Hai delle garanzie di
tipo "statistico" che i dati non si "addensino" in poche vaschette? / in
pochi files?
--- bye

Cmq... Io ancora non ho compreso tutto il problema... Ricapitolando... Hai
un quantitativo enorme di dati, e vuoi creare un indice con puntatori da 5
bytes a questi dati?
Oppure i 5 bytes SONO i dati?
--- bye

Cmq se guardi qui: 
http://www.mega-nerd.com/libsndfile/
 l'autore ha creato
una libreria che fa parecchia roba. Al suo interno un file serve per la
gestione "trasparente" di files a 64 bits. Il tutto č sotto LGPL mi sembra.
--- bye


--------------
Stiamo discutendo di qualcosa che sto ancora considerando,
l'organizzazione delle vaschette avviene ricorsivamente e il
mantenimento presuppongo autonomo durante la scrittura, "comunicando"
con la successiva,
l'astrazione delle vaschette non deve confondere la normale gestione
di un file.
Le vaschette servono soltanto per velocizzare gli inserimenti degli
elementi ordinati, in conclusione è come avere un file con
qualche byte in più "libero" per questo tipo di organizzazione,
l'archivio ordinato è solo una specializzazione del file archivio,
quest'ultimo in grado di gestire dimensioni discretamente
grandi.
Il mal di testa a 5 byte è solo un'interpretazione di posizionamento,
se 5 byte descrivono una posizione 0 -> ~+1.099Gb il file archivio
deve solo tradurre la posizione
es: file/vaschetta/posizione,
ipotizzo la formattazione: [0] / [0][0] / [0][0]

--------------
I 5 byte potrebbero essere una classe CPosFile che descrive il
posizionamento nel file archivio,
CPosFile è scritta su HD, non è un puntatore,
successivamente si potrebbe gestire in RAM una cache di CPosFile per
non continuare a leggere su disco, ma preferirei non
allargarmi troppo su dettagli secondari.
CPosFile è un riferimento all'oggetto che preferisco perchè garantisce
lunghezze fisse univoche (5 byte) e permette
un'ordinamento degli oggetti indipendentemente dal tipo.
buona giornata,
duido