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:perator+= that lets me
concatenate strings. Isn't ostringstream:perator<< 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

 

[Alf P. Steinbach]

* (e-mail address removed):

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

AFAICS nothing prevents you from defining operator<< for strings, e.g.
(off-the-cuff)

std::string& operator<<( std::string& a, std::string const& b )
{
return (a += b);
}

the only problem then being that it's not present in namespace std.

As to the rationale for why this isn't in the standard library, it's
probably best to ask in [comp.std.c++], which deals with questions about
rationale and evolution of the standard.

However, one possible explanation is that std::string is a bastard, the
result of an unholy communion between two different concepts (general
container and text string), with neither concept realized completely in
the result. std::string is simply one of the ugliest beasts on Earth.
Its main feature, the reason that it's used, is that it's standard.

Cheers, & hth.,

- Alf

 

[James Kanze]

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:perator+= that lets me
concatenate strings. Isn't ostringstream:perator<< 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:perator<<. Just an ostream:perator<<.

You are dealing with two different abstractions. The
ostream:perator<< (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.