Newsgroup: it.comp.lang.c
Titolo: Lettura a righe da file.

Salve a tutti ,
c''è un modo semplice per leggere linee da files ? Quello che fa ,ad
esempio, la funzione
LINE_INPUT nel linguaggio Basic ?
Ho un file di testo contenente :
Riga1
Riga2
Riga3
vorrei leggere riga per riga le stringhe in modo da riempire un array[i]
dove ogni i
contiene la stringa di una riga.
Non si conosce in precedenza la lunghezza di ogni stringa...
Ho provato con fgetc fermandomi quando trovo '\n' ma come faccio a "passare"
alla riga
successiva?
garzie
Nick
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
URL :       
http://www.Geocities.com/nick_hideout/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Ne pas aimer c'est un long mourir.
[Wu Ti]

 successiva?
Anch'io ho fatto Visual Basic:
a quanto ho capito vorresti implementare un:
dim a as string
do until eof(1) = true
    line input #1, a
    let me.text1.text = a
loop
In C esistono funzioni simili a queste istruzioni. Vi č la feof, ad esempio,
che come la eof, restituisce un int indicante - 0 1 - indicando a che
posizione si č all'interno del file.
Vi č anche un puntatore implicito, che in Visual Basic viene gestito dallo
strumento, ma in C dev'essere impostato manualmente tramite la funzione
fseek(FILE*, int, int).
Un'altra cosa, forse potresti usare la fgets al posto della rispettiva fgetc
in quanto lavori direttamente con un array di caratteri e non con un singolo
byte.
Ciao.

 Non si conosce in precedenza la lunghezza di ogni stringa...
#define MAX_LEN 128
...
char buff[MAX_LEN];
FILE *some_file;
...
fgets(buff, MAX_LEN, some_file);
...
Questo per leggere una riga. Poi, puoi allocare la memoria per la
stringa, copiarcela e memorizzare il puntatore nell'array:
ptr = malloc(strlen(buff)+1);
assert(ptr);
strcpy(ptr, buff);
array[i] = ptr;
(con char *ptr; char *array[n];)
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Al termine di un pranzo di nozze mi hanno dato un
amaro alle erbe cosi' schifoso che perfino sull'etichetta
c'era un frate che vomitava.

Devo implementare proprio quello!
Il fatto è che con fseek mi posso posizionare dove voglio ... ma non so
dove!
Riesco a capire quando arrivo alla fine della riga perchè trovo un '\n' ma
non
riesco a posizionare il puntatore all'inizio della successiva...
grazie
Nick

Okay, ma come faccio poi a leggere la seconda riga ?
thanks
Nick


Non hai nessun bisogno di fare nulla. Basta che continui a leggere.
In c il file e' un array di caratteri.... \n e' un carattere come tutti gli
altri
il carattere successivo sara' il primo carattere della seconda linea (questo
in Unix in dos avrai un carattere return (13) e poi il primo carattere della
linea successiva).
Il problema che ti si pone e' come fare a capire
quando finisce il file. Suggerisco di utilizzare feof.
                       Andrea


Grazie a tutti. Ora tutto funziona .
byez
Nick


 Okay, ma come faccio poi a leggere la seconda riga ?
while (fgets(buff,MAX_LEN,file)) {
	...
}
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Runtime error 6D at f000:a12f : user incompetente

dove!
Per utilizzare una fseek su file di testo e' necessario che la
posizione su cui ci si pone sia stata ottenuta con una precedente
ftell.
--
Walkie...@Libero.It (ICQ# 8143647)

quando finisce il file. Suggerisco di utilizzare feof.
Suggerisco di no.
Tutte le funzioni di I/O del C sono in grado di testare o meno questa
situazione con un valore di ritorno.
es.: 
while ( fgets( ... ) ) 
{
   ...
}
--
Walkie...@Libero.It (ICQ# 8143647)

 In c il file e' un array di caratteri....
Beh, non proprio. E' uno stream di caratteri che è una cosa un po'
diversa da un array.
EMG

linea successiva).
Anche se è vero che un file in DOS è terminato da \n\r (o \r\n, non ricordo
l'ordine, cmq c'è un CR ed un NL), tutti gli ambienti di sviluppo (DJGPP,
Cygwin) che ho provato fin'ora "fondono" i 2 caratteri in un solo \n se il
file è aperto in modalità testo.
In pratica non c'è da preoccuparsi della differenza finché si usano i file
di testo aprendoli come file di testo. Non so cosa dica lo standard in
proposito, ma il fatto che le funzioni di seek non siano affidabili quando
usate su file di testo mi fa credere che questo comportamento sia
esplicitamente previsto dallo standard.
Lanugo

esplicitamente previsto dallo standard.
Le funzioni di seek non sono affidabili su file di testo, quando le
posizioni scelte non sono state predeterminate da una ftell (o
fgetpos, da usare con fsetpos).
Secondo l'ANSI C Rationale :
Random access.
The UNIX I/O model features random access to data in a file, indexed
by character number.  On systems where a new-line character processed
by the program represents an unknown number of physically recorded
characters, this simple mechanism cannot be consistently supported for
text streams.  The Standard abstracts the significant properties of
random access for text streams: the ability to determine the current
file position and then later reposition the file to the same location.
ftell returns a file position indicator, which has no necessary
interpretation except that an fseek operation with that indicator
value will position the file to the same place.  Thus an
implementation may encode whatever file positioning information is
most appropriate for a text file, subject only to the constraint that
the encoding be representable as a long.  Use of fgetpos and fsetpos
removes even this constraint.

text streams.
Infatti, lo sospettavo: non sono affidabili perché in realtà viene letto un
\n al posto del terminatore di riga usato dal sistema (che può essere anche
più di 1 byte, es sotto dos). Di conseguenza, aprendo un file come testo non
ci sono problemi di terminatore: è il compilatore/libreria standard che si
preoccupano di filtrarlo e presentarlo con le linee terminate da un \n.
Lanugo

 Walkie...@Libero.It (ICQ# 8143647)
qui sono forse io un po' troppo pignolo. Ma la fgets potrebbe
tornare EOF anche in presenza di un errore e non solo perche'
e' finito il file. Mi rendo conto che e' una differenza non enorme....
ma se il file non risiede sulla stessa macchina, ma viene condiviso tramite
samba o nfs, puo' avere la sua importanza...
                                    Andrea Zaghi

e' finito il file. Mi rendo conto che e' una differenza non enorme....
fgets NON restituisce mai EOF, si tratta sempre di un valore 0 o
diverso da 0 (se non ricordo male).
--
Walkie...@Libero.It (ICQ# 8143647)

 tramite samba o nfs, puo' avere la sua importanza...
tratto da man fgets
RETURN VALUES
        fgetc(), getc() and getchar() return the character read as an 
        unsigned char cast to an int or EOF on  end of file or error.
 
        gets()  and fgets() return s on success, and NULL on error or 
        when end of file occurs while no characters have been read.

         when end of file occurs while no characters have been read.
Si mi ero confuso con fgetc getc e getchar,...
Comunque l'appunto rimane identico basta sostituire EOF con NULL :-)
                                                             Andrea Zaghi