Newsgroup: it.comp.lang.c++
Titolo: Un dubbio banalissimo con Builder..

Salve, scusate la domanda idiota, ma usando Borland C++Builder 3 mi sono
trovato spiazzato quando devo creare dei file, tipo: 1) dei file con record
fissi, 2) dei file di testo, 3) degli RTF. Per i primi 2 devo usare
iostream.h o qualcosa di più moderno? Nel builder non ho trovato niente di
specifico. E per il terzo?
Perdonatemi la domanda stupida, grazie a chi vorrà rispondermi!
Ciao
Michele

 3) degli RTF.
Una libreria esterna.
EMG

 Perdonatemi la domanda stupida, grazie a chi vorrà rispondermi!
Non so cosa abbia di specifico C++Builder (magari chiedi sul gruppo
it.comp.programmare.win32 per cose specifiche di un solo dato
compilatore e non del C++ standard), comunque, in C++ standard:
-- per qualsiasi file di testo (compreso RTF, che e` pure un formato
    di testo, con "mark-up") usi #include <iostream> (senza .h) e vari
    altri headerfile connessi, come <fstream>, e i vari operator<< che
    inseriscono testo nel file
-- per un file binario (sia "a record fissi" o altro) apri pur sempre
    un ostream (tipicamente un std::ofstream) con std::ios::binary
    come flag, e per scrivere i dati usi il suo membro .write
Alex

 wrote in message
[...]
| in C++ standard:
|
| -- per qualsiasi file di testo usi #include <iostream> (senza .h) e vari
|     altri headerfile connessi, come <fstream>, e i vari operator<< che
|     inseriscono testo nel file
|
| -- per un file binario (sia "a record fissi" o altro) apri pur sempre
|     un ostream (tipicamente un std::ofstream) con std::ios::binary
|     come flag, e per scrivere i dati usi il suo membro .write
Una domandina:
in win e dos, c'e' differenza tra i due tipi di files, per la conversione
"\n" in "\n\r" in scrittura e viceversa in lettura nei text, mentre cio'
non avviene nei binary.
Ma per gli altri? qual'e' la differenza? In unix e similari, non ce n'e',
prova ne e' che si puo' usare il cat per scrivere su /dev/fdo...
non so per MacOs...
e allora lo standard ha adottato un differenziazione che vale solo per
win/dos?
mah...

 win/dos?
No, vale per tutti i sistemi operativi mai inventati eccetto Unix e
derivati.  Anche a parte MacOS, non penserai che il C e il C++
possano trascurare OS/400, VMS, MVS, VM,  eccetera, vero?!
Incidentalmente, DOS trae il suo uso di \r\n da CP/M che a sua
volta lo trae da piu` antichi sistemi operativi Digital Equipment.
L'introduzione del concetto di "tipo di file" fu uno dei passi piu`
importanti nel rendere C un linguaggio utile non solo su Unix ma
anche su tanti altri sistemi.  Ovvio che lo standard C, che data da
molti anni dopo questa introduzione, non cancello` certo questa
preziosa features; e il C++ ne ha bisogno per la stessa ragione.
Tutti i protocolli di rete basati su testo prevedono \r\n come
separatore di riga, incidentalmente.  Questo e` comodissimo
da gestire *eccetto* che in Unix dove quel \r non di rado rompe.
E prova (con un cliente FTP triviale) a scordarti di definire il
tipo di quel che stai scaricando come Binary (o Image che
dir si voglia): arriva massacrato da una conversione a testo
(quanti megabyte buttati, in passato quando i clienti FTP piu`
triviali erano la norma, per questo dettaglio di progetto...!).
Alex

 wrote in message
| Unix e derivati sono l'eccezione.  La stragrande maggioranza dei
| sistemi operativi usa modi diversi di separare le righe di testo;
| MacOs usa[va] un \r invece del \n, ad esempio.  VMS e MVS,
| meglio non pensarci nemmeno (un migliaio di possibilita` diverse,
| da impazzire).
Ok, ammetto la mia ignoranza. Ma tutto questo rende comunque portabili i
listati, posto un compilatore aderente allo standard?
una piccola domanda: la dichiarazione standard delle
fstream::read(X* data, size_t size);
fstream::write(X* data, size_t size);
cosa prevede al posto di X?
char* (VC++, borland)
void* (g++, djgpp)
sospetto la prima...

 sospetto la prima...
Esatto.  std::basic_ostream<E>::write accetta un E* come primo
carattere, e std::fstream eredita (dopo varie peripezie:-) dalla
istanziazione std::basic_ostream<char>.
Alex