Re: string vs. ostringstream
On Jan 16, 6:48 pm, scho...@gmail.com wrote:
we often compose strings via a ostringstream and then create a string
from it. What is the rationale of not being able to use string in
place of a ostringstream, so I could write
string str;
str << ... << ...;
SomeAPI( str.c_str() );
Good design. Formatting is a different concern than just
holding text. (Not that std::string is particularly well
designed for managing text either. But then, I'm not sure, even
today, that we know enough to specify a definitive text type.)
Strangely enough, there is an string::operator+= that lets me
concatenate strings. Isn't ostringstream::operator<< also
implemented such that it first finds out the potential length
of its argument, then makes sure its buffer is long enough,
and then lets the argument fill the buffer with its
representation?
Not necessarily. Certainly not, in fact---there is no
ostringstream::operator<<. Just an ostream::operator<<.
You are dealing with two different abstractions. The
ostream::operator<< (and the free operator<< functions which
take an ostream& as their first argument) are concerned with
formatting textual output (and uniquely with formatting textual
output). They use the strategy pattern to handle the data
sink---what to do with the characters they generate. The
various streambuf classes handle data sinking and sourcing.
std::string is more or less just another container, with a few
extra operations, but with some important restrictions (e.g. it
can only "contain" POD types). But even if std::string were
"text", it would be important to separate the concerns of
formatting other types from it.
Note that "formatting", in general, is an awkward problem.
Obviously, you don't want to attach it to the data sink---why
should a file (or a string) know about your types. But
attaching it to the type being formatted isn't right either:
why should a simple type like e.g. complex be loaded down with
knowledge about all possible formats (normal text, XML, XDR,
BER...). In the end, iostream got it right: formatting is a
free function with a "standard" invocation sequence which
supports chaining.
Wouldn't the same work just as efficiently for string?
At the processing level, it could possibly be made to work even
more effectively. For the user, however, it would be a
disaster.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34