Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > string vs. ostringstream

Reply
Thread Tools

string vs. ostringstream

 
 
schoedl@gmail.com
Guest
Posts: n/a
 
      01-16-2008
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
 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      01-16-2008
* http://www.velocityreviews.com/forums/(E-Mail 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

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      01-17-2008
On Jan 16, 6:48 pm, (E-Mail Removed) 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: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.

--
James Kanze (GABI Software) email:(E-Mail Removed)
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Feeding string into ostringstream only uses up to the first null? coomberjones@gmail.com C++ 12 06-02-2008 03:14 AM
ostringstream output to C-string Fab C++ 4 03-24-2008 07:11 PM
std::string and std::ostringstream performances Bala2508 C++ 28 11-03-2007 03:22 AM
returning a string from an ostringstream Thomas Lenz C++ 7 10-23-2007 06:52 PM
Re: std::ostringstream unexpected behavior with .net 2003. Victor Bazarov C++ 0 06-25-2003 10:20 PM



Advertisments