View Full Version : [c] creazione file
billybilly
08-08-2006, 19:08
ciao,
sto facendo un programmino in c che mi crea un numero direi "stratosferico" di file.
per nominarli in modo differente ho pensato di ricorrere a un contatore....ma anche facendo un long double è troppo piccolo per le mie necessità.
ho cosi creato un char* x che inizialmente vale "1\0"...in pratica ho fatto una stringa.
Ogni volta che creo un file incremento il valore del mio char * tramite un apposita funzione...ma... nel momento in cui faccio un assegnamento del tipo : x[0]="1" (ho provato anche con apici singoli..... mi da un errore di segmention fault.....perchè????
se uqalcuno riesce riesci a darmi una risposta ne sarei molto grato.
Saluti Diego
devi creare più di 18.446.744.073.709.551.615 (18 miliardi di miliardi) di files...?!? :|
ti consiglio di cambiare design :|
PS: ma che HDD usi? e che filesystem?
trallallero
09-08-2006, 08:52
devi creare più di 18.446.744.073.709.551.615 (18 miliardi di miliardi) di files...?!? :|
forse deve contare le .dll di windows ?
:rotfl:
devi creare più di 18.446.744.073.709.551.615 (18 miliardi di miliardi) di files...?!? :|
ti consiglio di cambiare design :|
PS: ma che HDD usi? e che filesystem?
Concordo decisamente!
Non è che in realtà pensavi che un long double fosse pù piccolo? Controlla meglio :)
Concordo decisamente!
Non è che in realtà pensavi che un long double fosse pù piccolo? Controlla meglio :) quello da 18 miliardi di miliardi non è un long double, è un unsigned long long di GNU oppure un unsigned __int64 di Microsoft :D
sto facendo un programmino in c che mi crea un numero direi "stratosferico" di file.
per nominarli in modo differente ho pensato di ricorrere a un contatore....ma anche facendo un long double è troppo piccolo per le mie necessità. :D LOL triplo carpiato .... ma stai scherzando???
Per prima cosa dovresti dirci quale tipo di file system stai usando. In tutti i filesystem ci sono degli ovvi limiti per quanto riguarda il numero totale dei file e la dimensione massima di un file! Ad esempio per la FAT32 puoi avere al massimo 268.435.437 file mentre per NTFS puoi avere al massimo 4.294.967.295 (2^32 - 1) file.
Quindi si evince facilmente che un unsigned long (32 bit senza segno) dovrebbe esserti assolutamente più che sufficiente!!!
Poi facciamo una considerazione molto pratica: ammesso di avere, per pura ipotesi, 4.294.967.295 file nel tuo file system, supponendo che la dimensione di 1 cluster sia 4 KByte (dimensione tipica ma potrebbe anche essere di più), avresti bisogno come minimo di uno spazio di 17592186040320 Bytes, che equivale a circa 16 TeraByte. Hai l'hardware e le risorse finanziarie adatte per avere un sistema di storage da 16 TB??? :Prrr: :Prrr: :Prrr:
Ogni volta che creo un file incremento il valore del mio char * tramite un apposita funzione...ma... nel momento in cui faccio un assegnamento del tipo : x[0]="1" (ho provato anche con apici singoli..... mi da un errore di segmention fault.....perchè????
se uqalcuno riesce riesci a darmi una risposta ne sarei molto grato.
Saluti Diego
Perchè il C considera le stringhe dichiarate con char* stringa; in sola lettura, semplice.
Per ovviare fai char stringa[MAX_SIZE];
Per il nome usa un unsigned long non un double. Inoltre se devi cambiare il nome, considera che dopo il 9 (il 10 N.d.A) hai 2 cifre, quindi dovresti spostare il nome di un carattere a destra: il modo più semplice è leggere il nome del file in una stringa su cui fai degli strtok per recuperare le informazioni; quindi riscrivi la stringa con sprinft con le informazioni aggiornate.
Saluti
Perchè il C considera le stringhe dichiarate con char* stringa; in sola lettura, semplice. http://www.forumeye.it/invision/style_emoticons/default/harakiri.gif http://www.forumeye.it/invision/style_emoticons/default/harakiri.gif http://www.forumeye.it/invision/style_emoticons/default/harakiri.gif http://www.forumeye.it/invision/style_emoticons/default/harakiri.gif http://www.forumeye.it/invision/style_emoticons/default/harakiri.gif http://www.forumeye.it/invision/style_emoticons/default/harakiri.gif
BountyKiller
09-08-2006, 11:23
un long double è troppo piccolo per le mie necessità.
me cojoni...a parte che il long double nasce per numeri reali e non per interi (anche se è possibile usarlo come intero...) ma...... quanti file devi creare? lavori per il governo degli USA/cia/fbi/nasa? :D
me cojoni...a parte che il long double nasce per numeri reali e non per interi (anche se è possibile usarlo come intero...) ma...... quanti file devi creare? lavori per il governo degli USA/cia/fbi/nasa? :D no, immagino debba riscrivere il programma della cache di Google :rotfl:
BountyKiller
09-08-2006, 15:29
stavo pensando (seriamente) a una possibile soluzione del problema...la cosa più semplice che mi è venuto in mente è "wrappare" questo megatipo con una classe ah hoc che utilizza una struttura dati dinamica per esempio il vector della standard template library...
qualcosa del genere:
#include <vector>
using namespace std;
#define MAX_LIMIT 18 miliardi e rotti......
class mega_tipo
{
public:
static unsigned __int64 index;
megatipo() {great_buffer.push_back(0);}
void Increment(){
if(great_buffer[index]==MAX_LIMIT)
{
great_buffer.push_back(1);
index++;
}
else great_buffer[index]++;
}
private:
vector<unsigned __int64> great_buffer;
}
si potrebbero anche intercettare le eccezioni per capire quando trabocchiamo....in pratica raggiunto il limite aggiungo un altro "campo" unsigned__int64 e incremento quello...e così via finchè..................c'è memoria :D
è chiaro che poi bisogna gestire i vari campi del vector...non è banale ma nemmeno impossibile. eh eh
stavo pensando (seriamente) a una possibile soluzione del problema...la cosa più semplice che mi è venuto in mente è "wrappare" questo megatipo con una classe ah hoc che utilizza una struttura dati dinamica per esempio il vector della standard template library...E questo cosa potrebbe servire a billybilly? :confused: Lui dice che deve creare un numero "stratosferico" di file ....
Ma come ho già detto nel mio post sopra, ci sono dei limiti teorici, molto più stretti, ed anche dei limiti pratici ...
Ziosilvio
09-08-2006, 16:43
ciao,
sto facendo un programmino in c
[CUT]
Quoto tutto quello che hanno detto 71104 e andbin.
E aggiungo che faresti bene a prendere il Kernighan&Ritchie e studiarlo, soprattutto il capitolo 5.
Anche un'occhiatina a c-faq.com (http://c-faq.com/) non ti farebbe male.
a parte l'essere rimasto letteralmente sconvolto dalla richiesta :doh:
volevo solo fare una piccola precisazione per tutti quelli magari non molto pratici di C che dovessero capitare in questo post e leggere questa frase:
Perchè il C considera le stringhe dichiarate con char* stringa; in sola lettura, semplice.
desideravo solo precisare che non è assolutamente vero: il tipo char* non è altro che un puntatore a carattere, e come tutti i puntatori che puntano ad uno spazio di indirizzamento del processo stesso, sono accessibili in scrittura (come potrebbe un processo crearsi una variabile e precludersi la possibilità di scriverci? :muro: :muro: )
in realtà il puntatore punta ad una zona contigua di memoria di dimensione allocata precedentemente, quindi se dà segmentation fault è perché non c'è spazio allocato a sufficienza, ma se prima viene dichiarata la dimensione della stringa (anche inizializzandola direttamente, non solo mediante [<dimensione>])
essa è tranquillamente accessibile con dereferenziamenti del puntatore char*
scusate se magari sono andato un po' fuori post ma tenevo a precisare questa cosa per non confondere la gente che si avvicina al C
BountyKiller
10-08-2006, 08:44
E questo cosa potrebbe servire a billybilly? :confused: Lui dice che deve creare un numero "stratosferico" di file ....
lui usa dei numeri per dare i nomi ai file....con questo tipo dovrebbe riuscirci...ovviamente ci sono problemi a livello di rappresentazione del numero e bisogna lavorare un bel po sulla classe megatipo.....poi è anche ovvio che almeno per windows c'è sempre il limite massimo di 255 caratteri per il nome di un file....
vabbè.....comunque questa richiesta è veramente strana e bisognerebbe fare una memories delle richieste più assurde che si leggono e inserire questa
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.