Newsgroup: it.comp.lang.c++
Titolo: Fastidioso passaggio fra string e istream

Sto scrivendo un parser per un file di testo, e sto usando gli stream 
per leggere i file una riga alla volta.
 
Per farlo devo usare getline(), che vuole un char*, ma poi lavoro con le 
std::string che sono molto più comode per quello che devo fare.
 
Non c'è un modo per leggere direttamente una riga alla volta da un file 
di testo usando una std::string? Mi sta sulle scatole dover convertire 
tutte le volte da char* a string :-(
Vorrei avere una cosa tipo
 
Infile >> Line
 
ma che legga tutta la riga invece che fermarsi al primo spazio bianco. E 
(possibilmente) senza dovermi scrivere un operator>> apposta.
 
O meglio, mi pare impossibile che leggere un textfile una riga alla 
volta sia talmente raro e strampalato che il C++ non preveda di farlo 
direttamente con le string e gli stream... ma dai, devo per forza usare 
una vecchia char*? :-|

 std::string che sono molto più comode per quello che devo fare.
 
C'e' sia questa getline:
http://www.cplusplus.com/reference/iostream/istream/getline/
 
 
che questa, che ti riempie una std::string. che e' quella cerchi:
http://www.cplusplus.com/reference/string/getline/
 
 
Ciao


Volevo ben dire :-)
Ma perché non hanno semplicemente overloadato la getline di istream?
 
 

 Ma perché non hanno semplicemente overloadato la getline di istream?
 
Ci sara' qualche scelta di tener separato string da istream, mi pare che 
nessuna funzione in istream utilizzi string:
http://www.cplusplus.com/reference/iostream/istream/
 
Ciao

 nessuna funzione in istream utilizzi string:
 
Infatti è così (ho controllato esaustivamente ieri :-)
ma mi pare poco logico.
Magari è perché la classe string è stata aggiunta dopo che la istream 
era stata definita? Eppure non sarebbe stata una modifica chissà quanto 
pesante/invasiva.
 
Oh bè...


Come sapete sono un C-aro, per cui magari dico una ca**ata :-)
Direi che sono diversi concettualmente: gli stream sono pensati per 
flussi di dati dinamici, le string per.. beh, le stringhe (array di char 
di dimensione fissa). Per cui direi che non solo andrebbero tenuti 
separati, ma sono due aspetti opposti dell'accesso ai dati!
Ciao!

 separati, ma sono due aspetti opposti dell'accesso ai dati!
 
Le stringhe sono stringhe.
Come sono implementate è affare del C++, ma se c'è uno stream pensato 
apposta per essere usato con gli operator >>, << e compagnia io mi 
aspetto che sia così per tutti i tipi di dati nativi del linguaggio, e 
se non è così mi stupisco.


Eh, non è così semplice... Ad esempio, ti aspetti che tutti gli 
iteratori abbiano l'operatore + ? :-)
A volte i dettagli implementativi non sono solo dettagli, ma 
rappresentazioni fedeli degli oggetti astratti che descrivono..
M2C
Ciao!


Concordo. Le stringhe dovrebbero essere considerate alla stregua dei
tipi nativi del linguaggio, anche io mi aspetterei di trovare gli stream 
che dipendono dalle stringhe e non il contrario.
 
Evidentemente non e' cosi'... forse per ragioni storiche, dal momento
che ci sono in giro troppe varianti della classe stringa e non potevano
deciderne una a scapito delle altre... boh?
 
ciao
Giacomo

 deciderne una a scapito delle altre... boh?
 
No, non credo. La classe string e' stata standardizzata nel '94, quindi
relativamente subito. Si potrebbe cercare meglio, intanto ho trovato
questo: erano le line guida di Bjarne.
 
First of all, the key libraries now in almost universal
use must be standardized. This means that the exact
interface between C++ and the C standard libraries
must be speciﬁed and the iostreams library must be
speciﬁed. In addition, the basic language support must
be speciﬁed. ...
 
Next, the committee must see if it can respond to
the common demand for "more useful and standard
classes," such as string, without getting into a mess
of design by committee and without competing with
the C++ library industry. Any libraries beyond the
libraries and iostreams accepted by the committee
must be in the nature of building blocks rather than
more ambitious frameworks. The key role of a standard library is to ease
communication between separately developed, more ambitious libraries.
 
Da come lo leggo io, sembra che Bjarne avesse voluto che *prima* si
facessero gli iostream, poi le librerie.
 
 
 
 
 
-- 
-riko
http://www.enrico-franchi.org/
 
http://rik0-techtemple.blogspot.com/