468,504 Members | 1,946 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,504 developers. It's quick & easy.

string vs. ostringstream

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::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? Wouldn't the same work just
as efficiently for string?

Thanks for insights,

Arno
Jan 16 '08 #1
1 6877
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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jan 17 '08 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by __PPS__ | last post: by
3 posts views Thread by Someonekicked | last post: by
19 posts views Thread by Lionel B | last post: by
3 posts views Thread by Bob Altman | last post: by
5 posts views Thread by probstm | last post: by
25 posts views Thread by Bala2508 | last post: by
2 posts views Thread by Adam Nielsen | last post: by
9 posts views Thread by jl_post | last post: by
reply views Thread by NPC403 | last post: by
reply views Thread by fmendoza | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.