On 25 Nov 2002 at 22:31, Davide Bolcioni wrote:
> Purtroppo non è così. Tu pensi che ciò che hai scritto rispecchi ciò che
> tu pensi possa portare il programma a risolvere il problema, ma il
> compilatore non è così sveglio: prende ciò che hai scritto e applica
Distinzione estremamente corretta ma in certo qual modo poco pratica...
Se si vuole campare di certezze si muore a) ammazzandosi di lavoro
inutile b) contemplando questo brutto mondo cattivo.
Mettiamola cosi... la classe di equivalenza delle speranze ragionevoli
che un compilatore faccia quello che gli hai chiesto ;)
> Questa è una libreria: come si procura gli ingredienti non ti
Appunto questo è bene (tm).
> riguarda fino a che non scopri che ti ha vuotato le tasche per
> farlo.
uff che brutta gente che circola tra i programmatori di librerie.
> > Un altra cosa è:
> > vai a comperare patate, zucchine e biancostato, falle bollire...
> > aggiungi la pasta etc... piuttosto che vai a comperare fagioli, verze,
> > la gallina, falle bollire insieme al riso...
> >
> > Viene fuori il minestrone ma io stavo chiedendo 2 cose diverse.
> > E le penso in maniera diversa.
> > questo è male(tm)
> La differenza è solo nella tua visione del problema. Per aderire alla
Dici poco! Se reputassi la cosa irrilevante programmerei direttamente a
01. Se è necessario lo faccio anche... ma se non è necessario/utile
evito.
> tua metafora, alla fine hai sempre un minestrone - ammesso che tu ti sia
> espresso nei termini previsti. Se leggi la definizione p. es. del C++
> scopri che in vari posti ci sono frasi del tipo: se il programma è
> espresso in questo modo o quell'altro il comportamento è: - indefinito;
> - definito dall'implementazione.
Questo è un mondo difficile. Il problema che in una descrizione io
volevo il minestrone A nell'altra il minestrone B.
Se capita per problemi del compilatore che è carente è un problema da
risolvere... se io penso ad A e scrivo B è un mio problema,
ovvero penso a "dimensione file" e scrivo "apri e vai in fondo".
Allora nascondo il tutto sotto lo zerbino per 1000+1 ragioni (ho altro
da fare, non ho capito cosa stà sotto realmente a "dimensione file",
non conosco altro metodo, dipende dall'architettura e via dicendo) e
infilo in una funzione...
Il problema come si capisce in seguito grazie a un tuo suggerimento è
mal definito...
> Secondo te, cosa sarebbe "la" dimensione del file ?
In questo contesto è quello che caricherò in memoria quando lo leggo.
> > Non posso fare una classe di equivalenza tra scopi del codice perchè
> > il compilatore capisce il cosa ma non il perchè.
> Infatti se incapsuli il problema in una funzione, la chiami in un modo
> che ne suggerisca gli intenti e la usi sei a posto. Hai anche modo di
> scrivere qualche test della funzione stessa.
Il problema è che quando do le istruzioni per il minestrone A, e il
compilatore/libreria mi fa il minestrone B sotto il naso mi arrabbio...
La funzione "nasconde" il problema, ma il problema resta.
> > E per me il perchè è importante anche per _pensare_ al codice che
> > scrivo.
> >
> > Allora o non è possibile astrarre "dimensione del file", o nessuno lo
> > ha ancora fatto. Ma dammi la dimensione del file non è equivalente a
> > aprilo, vai in fondo e desumi la dimensione del file. stat è uno, il
> > giro di tellg seekg è l'altro.
> In generale, non c'è modo di stabilire quale sia la dimensione del
> file: in un sistema multiprocesso un altro processo può fare truncate()
> mentre sto scrivendo e Unix non fa una piega, il risultato è uno sparse
> file. Il seek offset è un offset che il kernel associa al file
> descriptor e usa soltanto quando riceve una read() o una write(), allo
> stesso modo la position di uno stream C++ è un off_t che viene usata
> solo al momento di << o >>, che peraltro lavorano in un buffer e vanno
> su disco solo quando necessario.
Questo è istruttivo ma non rilevante. Se non sapessi cosa chiedere, il
fatto che usi tellg() o stat sarebbe irrilevante... infatti per quanto
il mio punto di vista non cambi sul chiamare le cose con il proprio
nome... è stato sufficientemente istruttivo da farmi capire cosa devo
scrivere ma NON convincente abbastanza da farmelo chiamare f_size()...
> No, chi ha scritto lo standard semplicemente si è già scontrato con il
> problema per cui il concetto di dimensione del file non deve essere
> utilizzato da uno sviluppatore: nasconde troppe cose che possono andare
> storte. Offre quindi gli strumenti che consentono di arrivare a scrivere
> codice funzionante, facendo riflettere se ciò che serve è proprio la
> dimensione del file piuttosto che semplicemente essere sicuri di
> scrivere in fondo al file.
A conclusione di ciò si può solo dire che ne tellg() ne stat danno la
dimensione di un file perchè in un OS multiprocesso la dimensione di un
file è un concetto senza significato (quasi...).
Non potendo darmi la "dimensione di un file" o mi danno la _STESSA_
cosa sempre e io da domani la chiamo "proprietà pippo dei file" o mi
danno cose diverse e io non li uso in maniera equivalente.
Se mi danno la _STESSA_ cosa sempre allora posso considerare se mi
interessa di più l'efficienza, la nitidezza del codice, la
portabilità....
All'atto pratico mi interessava sapere la dimensione del file per
allocare _approssimativamente_ abbastanza spazio in memoria con la
possibilità di far crescere le dimensioni della memoria allocata ma di
limitare al minimo la frammentazione e le operazioni di allocazione.
Se si vuol cercare il pelo nell'uovo si può aggiungere dettaglio agli
obbiettivi:
a) se qualcuno aggiunge roba in coda voglio o no trasportarla in
memoria anche _dopo_ che ho letto le dimensioni del file?
b) se qualcuno continua ad agggiungere roba in coda in continuo cosa
faccio?
c) voglio/posso usare lock...
ovvio che seekg() si sposta dove è il "fine file" in quel momento.
stat da un'informazione "più stabile" ma anche più vecchia perchè
dovrebbe riferirsi alla copia sul FS e non al buffer (credo di aver
capito così), casualmente in questo contesto il concetto "dimensione
del file" sul FS ha più senso... tant'è che in stats c'è st_size :)
Conclusione
f.seekg(ios::end)
i=f.tellg()
NON è la dimensione del file dunque NON li metto in una funzione che si
chiama f_size(...) :)
anche se poi userò questo metodo per fare "previsioni" sull'allocazione
della memoria perchè stat non è utile anche se è qualche cosa che più
assomiglia a "dimensione file".
estremamente educativo e ottimo per riflettere... ma chiamare
quell'accrocchio f_size() e chiuderlo in una funzione senza capire cosa
_veramente_ stavo facendo era appunto nascondere la ruffa sotto lo
zerbino.
grazie per la pazienza... ma vedo che certi argomenti ti stimolano alla
loquacità ;)
--
Salve
Ivan Sergio Borgonovo
http://www.webthatworks.it/
uniq life || sleep 24h
|