Newsgroup: it.comp.lang.c++
Titolo: funzione flush()

Salve a tutti,
vi posto questo messaggio per sottoporvi un mio dubbio.
Leggendo Guida al C++ di Helbert Schildt (capitolo 18.6 parlando dell I/O
del c++) riporta (testualmente):
"..Tuttavia chiamando la funzione flush() è possibile ottenere forzatamente
la scrittura dei dati su disco prima che il buffer sia completo.
Il suo prototipo è il seguente:
ostream &flush();
Si consiglia di ricorrere alle chiamate a flush() quando un programma dovra'
essere utilizzato in condizioni ambientali avverse, dove per esempio si hanno
frequenti cadute di corrente."
E' corretto quello riportato????
Potreste essere cosi' gentili da indicarmi una condizione che necessita l'uso
di flush()???
Grazie dell'attenzione.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Grazie dell'attenzione.
1) quando l'output che stai emettendo non è di vitale importanza; ad
esempio, se questo output non ha ragione di esistere in caso di crash o
terminazione improvvisa del programma (file temporanei o cose simili), puoi
risparmiarti i flush;
2) quando la possibilità che si verifichi un'interruzione della normale
sequenza di operazioni prima della chiusura (e conseguente flush automatico)
dello stream, è abbastanza remota.
Questi sono solo suggerimenti. In ogni caso non esiste una regola precisa, i
flush vanno usati con giudizio e solo dove necessario, visto che possono
ridurre anche di molto le prestazioni dello streaming.
Marco

 E' corretto quello riportato????
sostanzialmente si, ma in ogni caso bisogna dire: "dipende". A seconda 
delle applicazioni se manca la corrente non sara` piu` possibile 
recuperare lo stato precedente, quindi e` inutile fare il flush.
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.73, higher than 99% of all previous test takers.
C Language: 3.79, higher than 92% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

recuperare lo stato precedente, quindi e` inutile fare il flush.
Perché? Se faccio una flush il file non viene effettivamente scritto
su file?
-- 
Marco Barisione (ICQ 84277092)

recuperare lo stato precedente, quindi e` inutile fare il flush.
Non e' vero.  Intanto i dati pendenti sono stati scritti.
Qualsiasi forma di flushing e' comunque utile.
-- 
Andrea Laforgia - walkietalkie(at)
libero.it
"Meglio cieco che negro" (Stevie Wonder)

su file?
flush semplicemente fa in modo che le librerie del C++
non mantengano nulla nei buffer interni. Da questo a
dire che i dati sono effettivamente finiti su disco
c'e' una bella differenza... c'e' infatti di mezzo il
sistema operativo e addirittura bisogna considerare
che oggi esistono controller di HD in cui la scrittura
"lazy" e' implementata anche a livello hardware.
Con VC++ su win32, ad esempio, e' possibile richiedere
che contestualmente all'operazione di flush dei buffer
venga anche effettivamente eseguita una "commit-to-disk"
ovvero venga anche chiesto a Windows di vuotare i *suoi*
buffer (che significa di piu' anche se come gia' detto
non garantisce comunque la scrittura fisica) ma per fare
questo e' necessario pero' fare il link di uno speciale
object file al progetto (COMMODE.OBJ).
flush come chiamata portabile ha un suo senso comunque...
ad esempio se due programmi vogliono parlarsi tramite
un file una chiamata di "flush" e' sufficiente (chi
gestisce gli altri livelli di caching lo fa in modo
coerente e quindi dopo aver fatto una flush una operazione
di lettura da parte di un altro programma trovera' i
nuovi dati anche se questi non sono stati fisicamente
scritti su disco).
Resta vero che le garanzie in caso di "caduta di corrente"
sono poche comunque...
Andrea

Qualsiasi forma di flushing e' comunque utile.
Non credo che il flush influenzi molto (una commit-to-disk
forse ha gia' una probabilita' maggiore di ottenre che i
dati finiscano su disco entro un tempo ragionevolmente
basso). La chiamata flush e' pero' fondamentale e
sufficiente se vuoi che diversi programmi si parlino
tramite file...
Andrea

 dipendono dal sistema operativo e anche dall'hardware.
Vero, ma gia' eliminare un primo buffering puo' essere utile.
Dire che chiamare "flush" e' inutile non e' corretto.
A me non e' mai capitato che, in seguito a una chiamata a 
flush, i dati venissero scritti su disco dopo un'ora e mezza.


 Non e' vero.  Intanto i dati pendenti sono stati scritti.
come ha fatto notare Andrea G. non e` detto, ma non era questo a cui mi 
riferivo. Semplicemente notavo che ci possono essere dei formati di file 
in cui avere solo meta` documento equivale a non avere nulla perche` 
magari ci sono delle informazioni essenziali alla fine.
Ad esempio, se non erro, da un file .zip parziale non riesci a 
recuperare alcunche`.


recuperare alcunche`.
Non ne sarei cosi' sicuro ...


 Non ne sarei cosi' sicuro ...
Infatti c'è un programma per ricreare il CRC recuperando il recuperabile..

 Non ne sarei cosi' sicuro ...
guarda qua: prova.zip e` un file valido:
[anto@localhost tmp]$ dd if=anagrafica.zip of=broken.zip count=1000
entrati 1000+0 record
usciti 1000+0 record
[anto@localhost tmp]$ unzip broken.zip
Archive:  broken.zip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of broken.zip or
        broken.zip.zip, and cannot find broken.zip.ZIP, period.


         broken.zip.zip, and cannot find broken.zip.ZIP, period.
No, c'è un programa per ricreare il file zip con i file *recuperabili*.
Comunque è OT.

guarda qua: prova.zip e` un file valido:
Stiamo uscendo fuori dal seminato.
Ci sono programmi in grado di compiere un "fix" dei .zip e
recuperare solo il recuperabile (credo che la stessa PKWare
avesse il suo pkfixzip o qualcosa del genere).
