Newsgroup: it.comp.lang.delphi
Titolo: Conta caretteri

Esiste una funzione in Delphi che sappia dirmi quanti caratteri sono
contenuto in un file tipo testo? Senza dover ricorrere alla lettura con Read
fino alla fine del file che ci mette un casino di tempo?
Grazie per la collaborazione
Lanfranco

Puoi fare un ciclo di readln e sommi la lunghezza delle stringhe lette. In
alternativa, se non te ne frega nulla dei caratteri tipo ascii < 32 (codici
di controllo - non visibili nel testo -) che possono esserci nel file basta
leggere la lunghezza del file.
Ciao, Sandro

fino alla fine del file che ci mette un casino di tempo?
Carichi il file in un TMemo e usi la funzione TMemo.GetTextLen
----
Lawrence "Rhymes" Oluyede
rhy...@myself.com

 tempo? 
Questa in C è una stra-FAQ, non facciamo le solite figure da pascalisti 
o peggio Delphisti (come quello che consiglia di usare un TMemo - 
maddai!): apri il file, sposti il cursore alla fine, leggi la posizione 
del cursore, chiudi il file. Non puoi farlo (non facilmente) con i tipi 
file e text, usa le funzioni di Windows
-- 
Nato nel vizio, morto nel supplizio
Nato nel peccato, ad entrare sia invitato

file e text, usa le funzioni di Windows
Non facciamo le solite figure di chi complica inutilmente le
cose, come quello che consigliava di usare le API di Windows
per qualcosa fattibile in modo molto piu' semplice -
maddaaai !
-- 
The Follet

maddai!)
io ho proposto una soluzione, una delle tante, non vedo il problema


meglio ancora, una TStringList.
Che è lento? Mangia-memoria? Assurdo? Freudiano? Che per queste cose, a 
volersi proprio fare del male con la VCL, c'è THandleStream? Peggio che 
Delphisti, qui passiamo per VBisti
In campana, eh


 Delphisti, qui passiamo per VBisti
Ma per favore... 
Non c'e alcun motivo per ritenere che l'approccio
orientato agli oggetti sia piu' lento e piu' 
dispendioso di risorse, rispetto all'approccio
procedurale classico.  Anzi, nella maggior parte
dei casi e' l'esatto contrario.
Sara' anche assurdo e freudiano, ma ti assicuro
che lo e' soltanto per te...
-- 
Posted from  [80.105.34.80] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 procedurale classico.
Nel caso specifico, lo e'. E' dispendioso e lento. Se il file di testo e' da
10 Mb che fai, lo carichi tutto in memoria dentro un oggetto? Ah, bella
tecnica :)
Non bisogna mica pensare "a senso unico", il programmatore deve valutare la
tecnica piu' adatta al caso che sta affrontando, mica perche' "sono di moda"
gli oggetti bisogna usarli sempre e comunque, no? ;)
Ciao, Sandro

 gli oggetti bisogna usarli sempre e comunque, no? ;)
Gli oggetti non si usano perche' sono di moda, gli
oggetti si usano perche' sono efficienti.
Sono passati i tempi in cui i programmatori erano
intimoriti dai "rischi" che si correvano 
nell'avvicinarsi alla programmazione orientata agli
oggetti.  Chi deve aprire gli occhi e' chi crede
ancora che un oggetto sia una forma troppo pesante
di fare le stesse cose che si fanno per via procedurale.
Gli oggetti sono astrazioni che consentono di trattare
le informazioni a livelli piu' alti e migliori di
quanto possa fare un programmatore.
Visto che in uno dei messaggi e' stato tirato fuori
il C, prova a dare uno sguardo alle prestazioni
della libreria standard del C e quella del C++.
La libreria standard del C++, che consta di diversi
oggetti predefiniti per operazioni piuttosto semplici,
e' infinitamente piu' veloce della lib std del C.
E questo perche', quando si progettano oggetti e 
gerarchie si puo' strizzare l'occhio alle prestazioni
da ottenere, senza che il programmatore ne sia
coinvolto.  Il vantaggio principale e' che se, domani,
Borland trova un metodo superveloce di compiere un
determinato compito che tu puoi replicare con l'uso
di un certo set di API, il suo prodotto sara' 
infinitamente piu' veloce del tuo.


Questo e' il tuo parere. Perfettamente legittimo, per carita'. Il mio parere
invece e' che non e' il caso di disturbare oggetti e astrazioni quando si
tratta di leggere il numero di caratteri in un file di testo. Ci sono
soluzioni piu' semplici e meno dispendiose in termini di memoria e risorse.
Con tre righe di codice e un migliaio di byte di ram puoi misurare file che
vanno da 1 byte a 1 terabyte, non hai necessita' di strutture dinamiche, non
devi appoggiarti al complesso sistema di gestione della memoria di Win,
ecc.ecc.
Insomma, siamo realisti: Dobbiamo fare 50 metri per andare a comprare il
giornale, ci vogliamo andare in elicottero? :)
Ciao, Sandro

 giornale, ci vogliamo andare in elicottero? :)
Appunto: per semplicita' usiamo gli oggetti, sono stati
inventati apposta.
Tu, comunque, rimani pure del tuo punto di vista.
Io ti invito a dare una lettura ai sorgenti della VCL
e a renderti conto di che cosa e' meglio: se costruirsi
le soluzioni da soli o trovarsele gia' belle e pronte, 
sicure, exception-safe e affidabili.
I programmatori vecchio stampo devono disilludersi di
saper fare le cose meglio di chi costruisce gli 
strumenti che utilizzano.


L'OOP è una tecnologia che va accettata _sempre_ se la si sceglie.
NON e' affatto vero.  E' una affermazione piuttosto semplicistica.
Tutto dipende dal contesto.
-----------
Ore 18.30: premo invio.

Ciao,
la funzione che si ricerca per conoscere il numero di caratteri in un file
testo serve per poter poi riutilizzare questo dato o solo per conoscenza
personale? perchè se è per conoscenza personale potete aprire Word, aprire
il file e andare nel menu Strumenti/conteggio parole...
se invece serve per poter riutilizzare il dato...fate finta di non aver
letto niente :-P
--
Cordialement,
Salvatore GIGLIUTO  4IF2
INSA-Lyon
20, Albert Einstein E616
69621 Villeurbanne Cedex

Perdonatemi se mi intrometto nella discussione.
Ho letto i post di The Follet e di Zortek e pur trovandomi d'accordo con
l'opinione di The Follet relativamente all'uso delle tecnologie OOP per la
risoluzione dei problemi, trovo che ci sia una cosa da evidenziare nella vs
discussione.
Il problema non è se sia necessario o meno utilizzare una classe, qundi i
servizi da essa offerti, per risolvere la questione proposta nello startung
thread, bensì se utilizzare una classe o un *componente* ...
Trovo quindi giusto affermare che utilizzare la classe TMemo sia
"esagerato", dato che ne impiegheremmo l'1% di funzionalità, ma allocheremmo
una risorsa windows, con tutto quello che ne consegue (es cattura dei mess,
ridisegno grafico), quando basterebbe una semplice classe per la gestione
dei files o magari utilizzare la soluzione che TMemo adotta *internamente*
alla classe per risolvere la richiesta (probabilmente si affiderà a classi
di servizio).
Perchè allocare una risorsa grafica per risolvere un problema così piccolo
(in rapporto alle risorse impiegate) ?
Il Biondo

che lo e' soltanto per te...
Tu davvero credi che editor come UltraEdit (per la cronaca, dimensioni 
massime consentite di un documento: 2^64 byte) carichino interamente i 
file in memoria? E poi, solo per sapere quant'è grande? Come dire, 
vediamo quant'è grande 'sto cocomero, me lo ficco in gola tutto intero


 Per la serie: la coerenza.
Caro il mio originale Jack Burton.
Io sono coerente con quanto affermo.
Punto primo:
Se si sta parlando di ReadLn e WriteLn e si dice
qualcosa di sbagliato su ReadLn e WriteLn, io ribatto
sull'argomento ReadLn e WriteLn, il che non 
c'entra nulla con quanto stiamo dicendo in 
questo thread.
Punto secondo:
Quando si afferma che un costrutto OO non lo si debba
usare a tutti i costi, io sono perfettamente 
d'accordo.  Val la pena utilizzarlo, pero', quando
si rivela maggiormente efficiente.
Nel caso del conteggio di caratteri di un
file di testo, e' un metodo efficiente.


 (in rapporto alle risorse impiegate) ?
Difatti e' meglio utilizzare una TStringList.


 E poi, solo per sapere quant'è grande? 
Ecco l'ennesimo elemento di confusione.
Per sapere quanto e' grande un file, basta leggere 
la sua dimensione, il nostro amico vuol contare
quanti caratteri ci sono.
Comunque questa e' l'ennesima discussione in cui
ciascuno cerca di far valere le proprie convinzioni,
per cui mi fermo qui.
Se volete usare gli stream usate gli stream,
se volete usare le stringlist usate le stringlist,
se vi volete sbattere con le API sbattetevi pure,
a me, onestamente, importa poco.


file di testo, e' un metodo efficiente.
Vedi mio caro Laforgia, ho la netta impressione che tu un vero e
proprio doppiopesistsa professionista:
ai tempi discutemmo (da alleati) sul fatto che utilizzare una
TStringlist per operazioni di lettura di grossi file di testo fosse un
errore. Oggi affermi il contrario.
Tutto il resto è fuffa.
Massimo.


 errore. Oggi affermi il contrario.
Caro Massimo Pini AKA The Original Jack Burton,
Allora affermai una cosa ed oggi affermo il contrario.
Questa non e' mancanza di coerenza, questo e' l'effetto di
essersi resi conto che quanto si affermava allora non e' del
tutto vero.  E' l'effetto che si ha quando si va a spulciare
e studiare i sorgenti della VCL e rendersi conto che, in 
realta', non c'e' alcun motivo per giudicare il metodo 
adottato da Borland inefficiente.
Se ti vai a rileggere i messaggi di allora, ti renderai conto
che la discussione e' divagata sul fatto che ReadLn e WriteLn
fossero funzioni obsolete, destinate per chissa' quale motivo
a morire, sul fatto che l'OOP vada adottata sempre e comunque,
per chissa' quale altro motivo.
Si puo' ribattere su questi punti, pur restando fermamente
convinti che la programmazione ad oggetti abbia degli utilizzi
efficienti nella maggior parte dei casi.
Tu rimani pure delle tue idee, gli "alleati" non mi servono.


 file di testo, e' un metodo efficiente.
..ridicolo..
Ciao, Sandro

 wrote:
Mmm mi dispiace che il mio post abbia generato tutto questo
dibattito.. Io _ribadisco_ ho solamente suggerito una soluzione, ciò
non significa che la mia sia la + efficiente ma è una delle tante...
ps. Laforgia, non ti avevo riconosciuto :-)


Tu rimani pure delle tue idee, gli "alleati" non mi servono.
Anche perché essere tuoi alleati, spesso, è come tirarsi una
martellata sui maroni :))))


ps. Laforgia, non ti avevo riconosciuto :-)
Ora che l'abbiamo scoperto, sarà di nuovo costretto a cambiare nick
eheheh (scherzo...;-)
-- 
(*metallikop*libero*it*)
{
http://web.tiscali.it/mbsoftware
}

 da imparare da questi dibattiti ;)
considera che ad oggi con i sistemi operativi e le potenze di elaborazione
attuali, qualunque metodo usi non sara' mai molto piu' lento o veloce di
qualunque altro, almeno su casi come quello citato nell'inizio del thread.
Discussioni come questa sono sicuramente interessanti, ma se fatte tra
persone ragionevoli e con una considerevole esperienza alle spalle. Non e'
il caso di questa discussione, permeata dall'arroganza di Laforgia che, come
al solito, rovina sempre i thread.
Ciao, Sandro

al solito, rovina sempre i thread.
Per me Laforgia in fondo in fondo è una persona buona, anche se ogni
tanto forse esagera. Ma dato che non ha ancora ucciso nessuno e dato
che è un buon programmatore e anche se non dice le cose nel modo
giusto (basta che siano giuste) a me va bene quindi teniamocelo ^_^


al solito, rovina sempre i thread.
Laforgia = The Follet = Walkie Talkie = varie ed eventuali :))) sarà
pure, come tu dici, arrogante (sembra infatti che gli dia fastidio
l'essere contradetto) però bisogna ammettere che l'esperienza ce l'ha,
che la mette spesso a disposizione di tanti niubbi che hanno imparato
qualcosa da lui, e che in questo thread sia stato lui a dire le cose
più giuste e interessanti: 
"Gli oggetti non si usano perche' sono di moda, gli
oggetti si usano perche' sono efficienti." Stavo pensando di
incorniciarla, questa frase :))))
-- 
(*metallikop*libero*it*)
{
http://web.tiscali.it/mbsoftware
}

oggetti si usano perche' sono efficienti."
se Laforgia me lo permette io la metto come signature


 wrote:

Basta farsene una ragione.
Considero TheFollet una persona intelligiente e con un'ottima
preparazione che ha, purtroppo, il difetto di voler fare il bastian
contrario per forza.
Cio nonostante trovo molti dei suoi interventi piů che sensati.
Amen.