Newsgroup: it.comp.lang.c
Titolo: record file testo

Salve, avrei due semplici domande da farvi:
- ho un file di testo in cui ad ogni riga corrisponde una parola (con
spazi). Vorrei convertire le parole (che sono tutte in maiuscolo) in
minuscolo, però a di tre in tre, cioè, voglio solo convertire le
parole appartenenti alla terza, sesta, nona,....,n-esima riga multiplo
di 3. Spero mi sia fatto comprendere asd.
Vorrei delucidazioni su come acquisire specifiche righe, anzichè una
dopo l'altra, prendendo tutto il file (piuttosto che sulla
conversione :D);
- Come faccio a cancellare una riga in un file di testo? cioè vorrei
un file con meno righe diciamo.. stesso problema: vorrei cancellare la
seconda, la quarta e ogni riga multiplo di 2 (come facessi 'backspace'
dal blocco note);
spero di essere stato chiaro, attendo vostre rispostee
ciaps :D


while () {
    if ((i%3)==0) {
    }
    ++i;
}
no?

 no?
si, deducevo il passaggio fosse quello. Però il contatore i, come
corrisponde alla riga in cui opero nel file di testo?
Ad esempio, se fp=fopen("prova.txt","r"), dovrò fare if ((fp%3)==0) ?
bo ._.

 dal blocco note);
Devi riscrivere l'intero file.
E.


Ti conviene ripassare come funzionano fopen/fclose/fgets.

 'backspace' dal blocco note);
E' un problema correlato al precedente, dove sotto
commento ho inserito la parte di scrittura. Conviene
lavorare con un file temporaneo in cui scrivi la linea che
ti serve. Una volta processato il file, chiudi entrambi,
cancelli l'originale e rinomini il secondo col nome del
file di origine.
ho scritto alla buona, il codice di cui sopra non sono
certo funzionerebbe così com'è esattamente, andrà
smanettato un po', eppoi è molto più uno pseudo-codice che
un frammento di c.
ciao ciao
Apx.

> while () { if ((i%3)==0) { } ++i; }
eh, sì certo che per funzionare funziona, ma se le righe
sono tante e va in overflow il registro che contiene "i"?

On 20 Dic, 16:22, Archeopteryx

E nel caso in cui vorresti contare le righe? :)
Comunque hai più che ragione, errore banale mio.

 Comunque hai più che ragione, errore banale mio.
No, l'errore è mio. Dopo aver letto il mio post mi sono
accorto che sostituendo con "unsigned long" si potevano
fare entrambe le cose e in quest'ottica la migliore
soluzione è la tua.
ciao!
Apx.

On 21 Dic, 14:04, Archeopteryx

Beh, un file con più di ULONG_MAX linee può capitare...

 soluzione č la tua.
Ma poi, cerchiamo di non farci troppi problemi. Se ho un file "bruto"
con 4 miliardi di righe, credo ci sia un problema di design, no?
-- 
-riko


Ma anche no. Immagina di leggere righe da una pipe, invece che da un
file regolare.

 file regolare.
Mi sembra sempre che una simile mole di dati *in genere* potrebbe
richiedere un più di analisi per vedere se è il modo opportuno di
gestire le cose.
Tipicamente se sto leggendo "a righe" ho a che fare con un file
testuale. Per questi tipi di files in genere compressioni anche blande
ottengono ottimi risultati. Per cui *a me* verrebbe da chiedermi se non
preferisco che i dati passino in altro modo. 
Per non parlare della bufferizzazione, che pure dovrebbe essere studiata
in modo ottimale. 
-- 
-riko


Non ho proprio capito. Su tutti i sistemi unix un applicazione tipica
legge dallo stdin, che poi a runtime sia attaccato ad un file, ad una
pipe o ad una interfaccia a caratteri non fa alcuna differenza, in
quanto il sistema ha una gestione totalmente trasparente di queste
astrazioni. Stessa cosa vale per lo stdout (e in generale per
qualsiasi file descriptor).
Ovviamente quindi è sempre meglio non fare supposizioni sull'input,
visto che potrebbe essere di qualsiasi tipo.
P.S. Si potrebbe obiettare che l'input è sempre sicuro quando siamo
noi a passarlo al nostro applicativo. E' uno dei punti dell'esistenza
della funzione gets(), considerata uno dei maggiori buchi di sicurezza
di sempre, ma utilizzata comunque quando l'input è considerato
"sicuro". Personalmente sono dell'avviso che la qualità di
un'applicazione risieda anche nella corretta gestione di input
totalmente inaspettati

 totalmente inaspettati
È sicuramente uno dei punti da tenere in considerazione. Ma io sto
facendo un discorso di efficienza, non di correttezza.
-- 
-riko

 dobbiamo fare un bel pò di ottimizzazioni *specifiche*. 
Perchè mai? Una applicazione che usa fgets per leggere le righe e ne 
stampa una su tre funzionerà beinissimo con files di qualunque 
dimensione. Cosa c'è da ottimizzare?
E.


Idem

 dimensione. Cosa c'è da ottimizzare?
IMHO e' si dovrebbe vedere se intervenendo sulla bufferizzazione di
lettura si ottengono performance migliori. Tipicamente la
bufferizzazione a linee potrebbe non essere ottimale.
-- 
-riko

 con emacs e 1K o 20Gb sarà lo stesso.
Uhm... cosa ti fa pensare che non usi abitualmente almeno uno dei due
editor? Ho appena fatto le prove con un file da 333 MB (ho 4 GB di RAM,
non e' che sto giocando con il muletto... :P).
vim impiega 15 secondi ad aprirlo, in seguito rimane piuttosto poco
reattivo. Emacs invece da:
byte-code: Maximum buffer size exceeded
E non procede. Ovviamente. Suppongo che secondo la tua classificazione
Emacs dovrebbe finire fra i pessimi. :P 
  Il mio editor favorito, TextMate, ha lo stesso comportamento: avverte
che il file potrebbe essere grosso e poi mi dice che non puo' procedere.
Viceversa TextWrangler, la versione gratuita di uno storico editor per
Mac, lo apre in meno di cinque secondi e non fa una piega. Pur essendo
un editor decoroso, di per se non fa un decimo delle cose che fanno gli
altri tre menzionati. Eppure a lavorare con files grossi se li mangia
tutti. Mi verrebbe da pensare che sia stato scritto pensando anche a
questa eventualita'.
Il punto e' che un editor da programmatori e' pensato con un altro caso
d'uso in mente... files piccoli.
-- 
-riko