Newsgroup: it.comp.lang.c++
Titolo: Domanda su fstream, come migliorare input/ouput?

Salve a tutti,
Giocando un po' con fstream, mi sono fatto alcuni programmini che
tengono dei dati su alcuni file di testo,
ho ad esempio un'agenda che tiene nome, tel, e mail.
Quando dopo aver preso i dati dall'utente li metto su file faccio:
ofstream out;
out.open("cacca");
out << name << endl;
out << tel << endl;
out << mail << endl;
e quando leggo:
iftream in;
int i=0;
in.open("cacca");
while(!in.eof()){
getline(in, nome[i], '\n');
getline(in, tele[i], '\n');
getline(in, mails[i], '\n');
++i;
}
E mi leggo 3 linee alla volta mettendole negli array che meglio
credo.....
Questo modo pero' non mi da modo di sapere se quello che metto
nell'array telefono e' davvero un numero di telefono.
Quindi come migliorare l'input output su file, in modo da sapere cosa
sto leggendo?
Mettere un prefisso del tipo <nome>, e poi quando prendo una stringa per
volta verificare se c'e' questo prefisso?
Idee migliori?
Grazie per l'aiuto
Whamoo

 Idee migliori?
Esistono due approcci fondamentali a questo problema: o dai per
scontato di leggere cio' che hai scritto tu, e quindi sai come e'
stato scritto e come leggerlo correttamente, ad esempio lasciando
degli spazi, o inserendo caratteri di separazione; altrimenti
codifichi in scrittura la natura di cio' che scrivi, ad esempio
inserendo etichette convenzionali, e leggendo verifichi che le
etichette siano quelle che ti aspetti.
A mio avviso il primo approccio e' preferibile nella stragrande
maggioranza dei casi, perche' il secondo comporta un sovraccarico
inutile.
Ciao,
Nicola

 inutile.
Quindi se so che cmq prendendo 4 righe per 4 righe la prima sara' il
nome, la seconda il tel ecc.... e al max una righa sara' vuota, mi va
bene lo stesso?
Sicuramente funziona, anche perche' in tutti i programmi che ho scritto
funziona, pero' mi pareva inelegante, ma se dite che e' uno dei metodi
piu' usati mi fido =)
Ok grazie mille, la smetto di crucciarmi
Whamoo

 piu' usati mi fido =)
A me pare piu' elegante *non* scrivere cose inutili.
Ciao,
Nicola

 sto leggendo?
XML. Il resto è nulla... :)
-- 
Luc

> XML
XML è il classico cannone per sparare alle mosche, in questo caso.

 wrote:

Ok, come usarlo? Come interfacciarlo al c++?
Fornire more information!! =)
Whamoo

> Ok, come usarlo? Come interfacciarlo al c++?
Dipende dalle piattaforme.  A seconda di quello che è il sistema
operativo e il compilatore da te utilizzato, rivolgiti a un gruppo
specifico: it.comp.programmare.win32 o it.comp.os.linux.development,
ad esempio.

 XML è il classico cannone per sparare alle mosche, in questo caso.
Forse si, ma magari per lui è un buon esercizio. E se poi il suo 
programma si sviluppa? 
-- 
Luc

 Fornire more information!! =)
Cerca, cerca, che c'è tanta robba in rete... ;) 
-- 
Luc

 wrote:

Urgh, quindi usando codice interfacciato all'Xml, ho un programma non
portabile?
A seconda della piattaforma devo fare delle modifiche al codice?
Bleah, per ora mi sto impegnando a scrivere il codice piu' portabile
possibile, e non ho intenzione di usare librerie che non lo siamo ;-)
Grazie comunque
(ps: non uso ne winzozz ne linux, macintosh forever, anche se il core
bsd e' il massimo)

 XML. Il resto   nulla... :)
XML si sta rapidamente conquistando il titolo di tecnologia piu'
abusata di tutti i tempi. Considerando poi che al meglio e' una
soluzione mediocre per tutti i problemi ai quali viene applicata ci
sarebbe da piangere.
Ciao,
Nicola

 sarebbe da piangere.
Scusa, puoi spiegare questa tua posizione, visto che tutto il "mondo che 
conta" in campo software sta portandosi sempre più verso l'xml? 
-- 
Luc

 portabile?
Non necessariamente, probabilmente esistono parser portabili (è
possibile costruirli rimanendo nei confini dello standard), però la
maggior parte della roba già pronta per manipolare file XML è legata
alla piattaforma (vedi DOM di Microsoft).

>conta" in campo software sta portandosi sempre più verso l'xml?
A parte che "il mondo che conta", in informatica (e specie in Italia)
è sempre più confinato a due o tre soggetti, la tua affermazione non
nega ciò che Nicola ha scritto.  XML non è necessariamente la
soluzione migliore e quando una soluzione viene applicata in *tutti* i
casi, finisce presto per essere inadatta per molti di essi.  A me,
comunque, questa tecnologia piace, è una delle cose migliori che siano
state inventate.  Sono d'accordo con Nicola, comunque, abusarne non è
mai bene, e questo vale per qualunque tecnologia.  Gli andamenti delle
software house, poi, sono dettati in gran parte dal mercato e solo
parzialmente da considerazioni di "qualità" tecnica, quindi questi
comportamenti "di massa" non li terrei in considerazione se si vuol
dare un consiglio a chi chiede come leggere/scrivere su un semplice
file di testo.


Non sono molto daccordo...
Un conto e' scrivere "programmini" per uso personale o didattico e allora
puo' valere tranquillamente il primo approccio.
Se realizzi software che deve fare produzione devi implementare un minimo di
controllo altrimenti non se ne esce vivi.

 controllo altrimenti non se ne esce vivi.
Con tutto il rispetto, č banale come rimarco.  E' ovvio che, laddove
possibile, bisogna controllare.  Il problema č che, in questo caso,
non č possibile controllare piů di tanto.  La sintassi di quanto letto
č controllabile, la semantica no, a meno di specificare un carattere
preciso, indicante il tipo di campo.  Quindi quanto proposto č giusto:
si da per scontato la *semantica* di quanto si sta leggendo.

 > controllo altrimenti non se ne esce vivi.
Mmmm, io gradirei sempre avere dei controlli su quello che leggo da
file, quindi ritornando alla mia domanda originale, come implementare
questi controlli? =)
Usare le funzioni di ricerca di string, includendo dei tag
identificativi?
Usare dei caratteri di separazione (il mio timore e' che l'utente possa
a sua volta usare uno di questi caratteri e mandare in pappa il tutto)
Altre idee?
Whamoo

> Con tutto il rispetto, č banale come rimarco.
Sicuramente, ma era soltanto il "e' preferibile nella stragrande maggioranza
dei casi" che non condividevo.
A mio avviso e' *sempre* preferibile verificare opportunamente almeno la
sintassi ed isolare eventuali casi di manomissione.
Se poi andare a verificare o meno la semantica e' una scelta da disquisire
in relazione alla singola casistica.


Premesso che i tag come i caratteri delimitatori presentanto la stessa
problematica di "mandare in pappa il tutto", utilizzare i caratteri
delimitatori ti impone di mantenere una struttura rigida nel formato del
file, mentre con dei tag guadagni sicuramente in leggibilita', versatilita'
(versioning) e anche nel caso ripristino di file danneggiati.
Da questo punto di vista l'XML non e' poi tanto male.

 Da questo punto di vista l'XML non e' poi tanto male.
Ok, quindi posso implementarmi un piccolo sistema di riconoscimento/uso
di tag, in modo da sapere sempre che cosa leggo e scrivo.
Non uso xml, perche' se ho capito bene non e' portabile al 100%, e devo
scrivere applicazioni il cui codice deve essere preso e ricompilato
senza modifiche =)
Grazie
Ciao 
Whamoo

 di tag, in modo da sapere sempre che cosa leggo e scrivo.
eventualmente puoi scriverti una qualche serie di classi gestire
espressioni regolari (eventualmente ci possiamo lavorare insieme
all'uni, visto che pure io ho una discreta voglia di implementarmele),
oppure usarne di gia` fatte [ magari in questo modo sono piu`
ottimizzate e potenti ].
-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
    - Brian W. Kernighan


cmq siamo OT [se vuoi andiamo in mail]


 ottimizzate e potenti ].
L'idea di implementarle in duo mi intriga, mi gusta usare cose fatte da
me ( come ben sai ;-) ), dai diciamo che si puo' fare, implementiamo una
bella libreria per la gestione dei tag in std C++, cosi' da fare
qualcosa di utile per il mondo =)
Whamoo

...

Il controllo deve essere commisurato all'importanza dei dati ed
all'aspettativa di errore. Se lavori sul sistema locale e sei
ragionevolmente sicuro che nessuno pasticci i tuoi file i controlli
non hanno senso. Soprattutto non ha senso moltiplicare per qualche
ordine di grandezza l'attivita' di scrivere e leggere.
Ciao,
Nicola

...

Anche qui, dipende dalla complessita' del contesto. Stiamo parlando di
una rubrica telefonica. In questo caso il buon vecchio formato dei
file di configurazione di Unix e' piu' che sufficiente:
Nome Cognome:via dei Tigli 15:02987654
Se proprio l'OP vuole essere sicuro puo' aggiungere un checksum in
fondo. In un caso come questo proporre XML e' una bufala di
proprorzioni colossali.
Con il mio suggerimento l'OP legge il suo file con una chiamata a
scanf(); XML sara' anche elastico ma hai voglia di quante modifiche
riesce a fare al suo programma prima di giustificare l'overhead.
Ciao,
Nicola Musatti

 conta" in campo software sta portandosi sempre pi  verso l'xml?
Se per mondo che conta intendi Microsoft, mi pare che sono abbastanza
noti per l'approccio "taglia singola per tutti". Non che Sun, IBM,
Oracle, ecc. non stiano imparando la lezione.
XML ha un pregio innegabile: specifica sia la rappresentazione del
contenuto che della sua struttura, cosa indispensabile per la
realizzazione di strumenti di manipolazione indipendenti dalla
semantica, ma non dalla sintassi, come ad esempio traduttori di
formato.
Il difetto fondamentale e' che la sua sintassi e' quella di un
linguaggio di "markup". In inglese "to mark up" significa
"evidenziare"; questo funziona in HTML, dove e' necessario evidenziare
un numero relativamente limitato di istruzioni di visualizzazione
all'interno di semplice testo. Nel caso dell'XML e' tutto markup;
questo comporta una scarsissima leggibilita' per gli umani, che fanno
fatica a trovare velocemente quello che cercano anche utilizzando
editor appositi e dei pesantissimi overhead di
memorizzazione/trasmissione/elaborazione dei dati. Insomma buona
l'idea, scarsa la realizzazione. Senza contare che la
metarappresentazione e' si una cosa importante, ma non per questo
bisogna per forza usarla ovunque e comunque.
Ciao,
Nicola

 memorizzazione/trasmissione/elaborazione dei dati.
Di solito non leggi un XML "a mano", ma magari un output fornito da un 
XSL apllicatogli.
Per quanto riguarda l'hoverhead e meglio essere prolissi ma chiari, e 
poi i tempi di trasmissione, oggi, sono di secondaria importanza. 
-- 
Luc

 XSL apllicatogli.
Si parla di manipolazione di dati in XML, per leggere documenti in XML
si usano dei parser appositi.  XSL serve ad applicare delle classi di
un CSS agli elementi presenti in un XML.  Vale solo per scopi di
visualizzazione, quindi non c'entra nulla con quanto si sta dicendo.

 Si parla di manipolazione di dati in XML
Mi sembra che il parser DOM sia ben fornito per queste operazioni... 
-- 
Luc

 ordine di grandezza l'attivita' di scrivere e leggere.
E' un costo che si paga una sola volta e poi si vive di rendita.

 prescindere.
In programmazione molte cose si fanno *a prescindere* e tante altre
no.  Garantire l'integrità dei dati, *a prescindere*, quando non ci
sono situazioni (o perlomeno è raro che vi siano), in cui tale
integrità è violata, è una perdita di tempo.  Non dico che non serva,
ma solo che fa perdere del tempo e se si cerca un compromesso
intelligente, si evita di perdersi in dettagli inutili.

> Mi sembra che il parser DOM sia ben fornito per queste operazioni...
E quindi ?  Per la serie: complichiamo le cose facili in difficili,
attraverso le cose inutili.  Oltretutto DOM significa COM (che a sua
volta significa bug) ed è quindi una soluzione proprietaria (una di
quelle di cui parlavo in un'altra parte del thread).

 riesce a fare al suo programma prima di giustificare l'overhead.
Anche l'XML lo puoi leggere con una scanf()!
Scherzi a parte e' proprio l'OP che voleva sapere :
| Quindi come migliorare l'input output su file, in modo da sapere cosa sto
leggendo?
Perdona forse la mia presunzione ma un checksum e i due punti non mi
sembrano la risposta giusta alla sua domanda...

 integrità è violata, è una perdita di tempo.
Secondo me non e' mai una perdita di tempo: basta che succeda anche soltanto
una volta per ringraziare di averlo fatto.

 poi i tempi di trasmissione, oggi, sono di secondaria importanza.
Solo se tratti pochi dati. Noi dobbiamo caricare ogni notte una marea
di aggiornamenti che ci arrivano da tre o quattro sistemi diversi, in
modo da essere attivi all'inizio della giornata lavorativa. Gia'
adesso se qualcosa va storto il tempo per mettere a posto le cose e'
spesso insufficiente. L'overhead di un formato tipo XML sarebbe non
solo inutile, ma gravemente dannoso.
Ciao,
Nicola

...

Non so se vi siete intesi, ma il problema non si sposta comunque. XML
richiede troppo lavoro per qualunque cosa tu voglia farci.
Ciao,
Nicola

 richiede troppo lavoro per qualunque cosa tu voglia farci.
Be', dipende su chi grava questo lavoro.  Se utilizzi un tool già
pronto per la gestione di file XML, il lavoro da fare per il
programmatore è minimo... o no ?

 programmatore è minimo... o no ?
Confermo. Noi usiamo una nostra classe wrapper del DOM che permette di 
manipolare file xml in modo "banale". 
-- 
Luc

 solo inutile, ma gravemente dannoso.
Di la verità, dai. E' roba M$ e non ti va giù. Non sei il primo, eh... 
;) 
-- 
Luc

manipolare file xml in modo "banale".
Che brutto vizio.  Di questi wrapper ne ho visti fare decine di volte.

 Di questi wrapper ne ho visti fare decine di volte.
Ma il ns è il migliore... E pensa... non l'ho fatto io, strano, eh? :-P 
-- 
Luc

 Di la verit , dai. E' roba M$ e non ti va gi . Non sei il primo, eh...
Nel caso specifico non e' cosi', dal momento che su XML puntano in
tanti. Tra l'altro Microsoft ci e' pure arrivata relativamente tardi,
tant'e' che i parser XML nascono in Java...
Ciao,
Nicola

 tant'e' che i parser XML nascono in Java...
Eh già... basta vedere SAX...