string vs. ostringstream

[schoedl]

Hello,

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() );

Strangely enough, there is an string::operato r+= 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? Wouldn't the same work just
as efficiently for string?

Thanks for insights,

Arno

[James Kanze]

On Jan 16, 6:48 pm, scho...@gmail.c om 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::operato r+= 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::operat or<<.

You are dealing with two different abstractions. The
ostream::operat or<< (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:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]