Newsgroup: it.comp.lang.delphi
Titolo: Aiuto: File I/O

Mi potete fare un semplice esempio su questo argomento:
1) Aprire un file di testo
2) leggere alcuni (o tutti?) dati
3) elaborarne alcuni
5) salvare il tutto in un nuovo file, con aggiunta di testo.
Cosa devo usare?
TMemoryStream, TFileStream, Memo1.Lines.LoadFromFile...???
Ho visto ad es. che Memo1.Lines.LoadFromFile carica TUTTE le stringhe nel
memo e non da la possibilità di lavorarci sopra (es. se volessi leggere un
dato numerico di una stringa per passarlo ad un'espressione non lo potrei
fare).
Gradirei qualche linea di codice di esempio (supponiamo che il file abbia 5
linee di testo ed io debba leggere o elaborare i dati della seconda e quarta
linea).
Grazie
Stefano

linea).
Per maggiore efficienza io continuerei ad usare le care vecchie
ReadLn/WriteLn.
program Prova ; // non COMPILATO !
var F : TextFile ;
    I : Integer ;
    MyStrings : array [1..5] of String ;
begin
  AssignFile( F, 'MIOFILE.TXT' ) ; Reset( F ) ;
  I := 1 ;
  while ( not Eof( F ) ) and ( I <= 5 ) do
  begin
    ReadLn( F, MyStrings[I] ) ;   
    Inc( I ) ;
  end ;
  CloseFile( F );
  ElaboraStringa( MyStrings[2] ) ;
  ElaboraStringa( MyStrings[4] ) ;
end ;

 ReadLn/WriteLn.
Ti ringrazio molto del suggerimento e dell'esempio, Walkie Talkie.
Credo si tratti della cosiddetta modalità console, vero?
Io però avevo bisogno di fare un'applicazione pienamente GUI (avevo già
fatto un programma del genere in Turbo Pascal).
Possibile che non si possa fare più velocemente e senza troppi problemi con
il Delphi??
Non c'è modo di fare un'applicazione tutta a 32 bit senza readln e writeln?
Ciao
Stefano


Prego,
Andrea

Non c'è modo di fare un'applicazione tutta a 32 bit senza readln e writeln?
piu' che una questione di bit, vedrei una questione di velocita' di
sviluppo, usare readln e writeln quando hai gia' delle *classi* belle
e pronte e facili da usare e' uno spreco... usa TStringList come
suggeritoti da DeerBear
Ciao,
Alan Solo

Alan Solo
Sara'... pero' ho i miei dubbi e non e' solo una questione di
efficienza. Metti di dover fare il parsing su un file di testo diciamo
di una sessantina di mega e prova a fare un TStringList.LoadFromFile.
Piuttosto userei, se non fossi ormai fossilizzato con vecchie
abitudini, un TFileStream, ma perche', quando non e' necessario,
complicarsi la vita? Readln per file di testo resta il metodo piu'
efficiente -- naturalmente, rigorosamente, IMHO -- ;)
Ciao,
Massimo.
-- 
"Ciao Rex, che cavolo di situazione eh? Due dentro, due fuori, puo' succedere di tutto!"

efficiente -- naturalmente, rigorosamente, IMHO -- ;)
Sono d'accordo.


Ciao,
Andrea

Un'altra cosa, quasi quasi dimenticavo.
E che succede ai tuoi SW se per qualche ragione Readln non viene più
supportato?
:=)
Andrea

Questo, ovviamente, rigorosamente, religiosamente, IMVHO
Il Fatto che assign si chiami assignfile, close closefile non mi
sembra sia una discriminante (tra l'altro puoi ancora usare assign e
close).
Vediamo perche': ho un file con un bel LF CR a fine riga, ho diciamo,
50.000 righe e devo leggerle tutte.
AssignFile(F, NomeFile);
Reset(F);
while not Eof(F) do begin
  Readln(F, L);
  ...........altro codice ...........
end;
CloseFile(F);
Finito. Cosa c'e' di complesso o di obsoleto?
Non ti posto lo stesso sistema con TFileStream perche' e' tardi e
voglio andare a casa :) ma non credo si possa fare altrettanto
semplicemente. Poi sul fatto che un codice debba essere
necessariamente *completamente* OO non mi trovi per nulla convinto,
forse l'uso di api e' OO?
Mah, forse sto diventando un reazionario della programmazione ;) e mi
piacciono ancora tanto i readln e blockread ...
Buon weekend a tutti.



Anghe a de!
Andrea

efficiente -- naturalmente, rigorosamente, IMHO -- ;)
si' beh, chiaro ... ci sono sempre i casi limite ...
solo che io lo vedo piu' naturale  (con Delphi... o con un RAD in
genere) usare la classe TStringList... facile da usare, chiara e ..
standard...
vuoi visualizzare il contenuto del file in un memo?
tac! Memo.Lines := StringList;
vuoi metterlo in un comboBox?
ComboBox.Items:= StringList;
vuoi cercare una stringa? indexof('stringa')
vuoi ordinarla .. sort ...
insomma, e' una comodita'.. certo che se si hanno grossi problemi di
velocita' bisogna rispolverare le "vecchie" funizioncine "old-school"
;)
Ciao,
Alan Solo

se non per usarli? :=)
Il problema e' che non sempre cio' che e' OO e' performante rispetto
al vecchio.  In C++, per esempio, esistono gli "stream" a livello
standard, ma e' massacrante cercare di convertire una std::string in
valore numerico usando uno stringstream.  Molto + efficiente
rivolgersi alle care vecchie atoi/strtol e varianti.


Sarei d'accordo con te se non fosse che ciò che è OO, in quanto OO, può
essere migliorato.
Questo con le atoi( conversione di stringa ad intero ) e strtol( conversione
di stringa a long, giusto? :=) ) non lo puoi fare.
Qui il discorso "non verranno più supportati" non si può fare( chi mai
mollerà il C per compiti "critici"? ) però uando usi le classi puoi
intercambiarle finché sono "compatibili" ( mai sentito parlare di
polimorfismo?
prova a farlo con atoi o con printf... ;=P ).
Infine, c'è una ragione di design... continuando di questo passo è chiaro
che le applicazioni diventano immantenibili.
L'OOP è una tecnologia che va accettata _sempre_ se la si sceglie.
Non vorrei buttarla sul fanatismo, però trovo che sia molto più semplice in
fin dei conti usare metodi OO.
Non ne faccio una questione di velocità( e sinceramente mi domando che
differenza ci sia quando oggi i computer hanno almeno un processore di
classe Pentium I in media ).
Ciao,
Andrea

classe Pentium I in media ).
Il fatto che le diverse velocita' non siano apprezzabili, non vuol
dire che non si debba fare nulla per migliorare le prestazioni.


Si, ma non significa nemmeno che bisogna spremere l'ultimo millisecondo.
Ciao !
Andrea

E questo non sempre è un bene.
I progettisti di Delphi non si troveranno mai nella necessita' di
buttare via una delle due: hai mai visto le librerie c? Puoi trovare
anche 20 funzioni che, piu' o meno, fanno la stessa cosa.




Guarda che io sono il primo a usare TStringList quando e' utile. 
Il fatto e' che nel nostro caso non lo e'.
E questa e' la cosa che mi spaventa di piu' dei nuovi RAD: certe cose
sono troppo banali, si rischia di perdere di vista le basi, il
*perche'* delle cose. Non lo so, forse mi sbaglio, ma oggigiorno vedo
in giro un sacco di vaccate nei codici che 10 anni fa non avrei mai
visto e non perche' eravamo piu' bravi ma perche' il codice stesso
perdonava meno e se faceva schifo non funzionava.
Vuoi ordinare una una lista di stringhe? Tac, TStringList.Sort. QUANTE
persone sanno come si fa un sort e perchč? 



Andrea

Si, ma non significa nemmeno che bisogna spremere l'ultimo millisecondo.
Dipende ...
Prova a scrivere un'applicazione real-time...

Quindi, bene o male, il programmatore è "costretto" a sapere almeno le basi.
Ti rendi conto delle cose che dici ?
Tratto dal dizionario dell'UCCS (Ufficio Complicazione Cose Semplici),
il termine UDF sta ad indicare una User Defined Function, ovvero una
funzione scritta dall'utente, ovvero una funzione.  Ci tenevo a dirlo
per evitare che qualcuno pensasse a qualcosa di male.
Quindi la sort deve comunque usare una "funzione" di confronto scritta
dal programmatore, ma e' una funzione che non entra per niente in
contatto col meccanismo interno del confronto (non ti obbliga a sapere
nulla sull'algoritmo di confronto).
E' cioe' una funzione che si limita ad indicare la relazione d'ordine
da applicare all'insieme di dati da ordinare (<, >, <=, >=, ecc..)
Vedi qsort del C.

persone sanno come si fa un sort e perchè? 
beh, dai anch'io in terza superiore ho usato i file tipizzati (e file
impaginati.. che pizza! ;)) pero' poi si e' comnciato ad usare db e
sql... e' piu' semplice fare select a from tabella inner left natural
join pippo where campo>= (select max(numero) from altratabella
where tizio*tabella.camp<100)
order by tuaZia group by campoX having Max(campoX=666) ????
o scriverti una funzione, farti una ventina di cilcli, ecc... ???
;)
.. insomma, dai, lo so che e' un altro discorso, ma poi non poi tanto
distante...
Ciao,
Alan Solo

o scriverti una funzione, farti una ventina di cilcli, ecc... ???
Probabilmente mi sono espresso male, non voglio sebrare quello che ha
nostalgia del v.i. di unix perche' chi lo sapeva usare era _figo_
semplicemente ho espresso l'impressione -- personalissima -- che in
*alcuni casi* la preparazione dei nuovi programmatori non sia quella
di un tempo in quanto certe basi teoriche che una volta erano
necessarie ora sono, fino a certi livelli, non piu' tali. 
Per il resto io sono un grandissimo sostenitore del RAD.
Ciao,
Massimo.
P.S.
Ho provato a ordinare la tabella per MiaZia ma mi esce un errore, cosa
puo' essere? E colpa di MioZio :-)


puo' essere? E colpa di MioZio :-)
puo' essere ;)... cmq non so (sei OT :-PPP))
Ciao,
Alan Solo

necessarie ora sono, fino a certi livelli, non piu' tali. 
Premetto che sono d'accordo con quanto affermi nei messaggi.
Il fatto e' che e' cambiato nel tempo il concetto di "programmatore".
Oggi uno si sente "programmatore" non appena comincia a smanettare con
la tastiera.  Anni fa il mestiere di programmatore era molto meno
diffuso, anche' perche' piu' difficile.
Poi c'e' da dire anche un'altra cosa.
L'OOP viene tanto vantata (bada, io sono uno dei suoi sostenitori) ma
a volte a sproposito.  E' tipico di chi conosce poco la programmazione
voler usare a tutti i costi i costrutti object oriented, anche la'
dove non ce n'e' un reale bisogno.  Non e' vero che ovunque si
programma in modo classico, conviene programmare in modo
object-oriented.  Tutto dipende dalle applicazioni da sviluppare.

 ha scritto nel messaggio
news:3aed8561...@news.libero.it...

Sono _quasi_ d'accordo con il tuo post( ed in certi aspetti lo condivido ),
ma :
1) Se devi sviluppare in realtime, forse lo farai con il C piuttosto che con
il C++ no?
2) Se devi sviluppare un sistema di meccanizzazione, preferirai il C al C++
3) Se devi sviluppare un software di controllo di uno shuttle che ti faccia
Terra-Luna, userai Ada.
Se devi sviluppare un software di controllo magazzino con tanto di report,
sceglierai Delphi !
Se devi sviluppare una ISAPI userai VB... cioč Delphi, scusa mi sono
confuso... :=)
VB non lo userei mai, potendo scegliere... :=)
Ma se scegli di usare gli oggetti  _sempre_( come sarebbe giusto ) hai dei
vantaggi che trascendono il millisecondo risparmiato. Quali sono questi
vantaggi?
Innanzitutto se una classe non va, la puoi cambiare con una compatibile.
In secondo luogo, sulle classi puoi fare operazioni che sulle funzioni non
puoi fare.
Questo č quello che penso, che ti piaccia o no! :=)
Andrea

object-oriented.  Tutto dipende dalle applicazioni da sviluppare.
e su questo non ci piove ;)
anche se pendo verso l'OO... vorrà dire che non conosco bene la
programmazione ;)
Ciao,
Alan Solo

puoi fare.
Tutto cio' che e' fattibile con le classi e' parimenti fattibile con
le funzioni.  Ricordatelo.
Con questo non voglio dire che uso le funzioni e butto via le classi
(ripeto, sono uno dei primi sostenitori della materia OO), ma e' da
ingenui pensare che il modello OO si adatti sempre bene a qualsiasi
problema.

programmare (che è e sarà il modo "del presente e .. del futuro" ;))
Non e' un problema di adattamento.
Si poteva parlare di adattamento una decina di anni fa.
Ormai quasi tutti gli ambienti di sviluppo sono orientati agli
oggetti.  Abituarsi all'OO e' giusto e necessario, ma non bisogna
diventare fondamentalisti dell'OO, mettersi il prosciutto sugli occhi
e non guardare altro, perche' alla fine ci si rende ridicoli.

e non guardare altro, perche' alla fine ci si rende ridicoli.
... gia', ti immagini uno che va in giro col prosciutto sugli occhi?
... ridicolo, sì... direi di sì... 8)
cmq, ok come ho detto anch'io dipende dal progetto, e *ripeto*, quando
posso *io* penso in OOP...
un'altra cosa (domanda) che mi viene in mente, in kylix ci sono
AssignFile & Company?
Ciao,
Alan Solo

AssignFile & Company?
Non lo so, ma non vedo perche' non dovrebbero esserci.