string vs. ostringstream

Discussion in 'C++' started by schoedl@gmail.com, Jan 16, 2008.

  1. Guest

    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::eek:perator+= that lets me
    concatenate strings. Isn't ostringstream::eek: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
    , Jan 16, 2008
    #1
    1. Advertising

  2. * :
    >
    > 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?
    Alf P. Steinbach, Jan 16, 2008
    #2
    1. Advertising

  3. James Kanze Guest

    On Jan 16, 6:48 pm, 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::eek:perator+= that lets me
    > concatenate strings. Isn't ostringstream::eek: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::eek:perator<<. Just an ostream::eek:perator<<.

    You are dealing with two different abstractions. The
    ostream::eek: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:
    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
    James Kanze, Jan 17, 2008
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Victor Bazarov
    Replies:
    0
    Views:
    836
    Victor Bazarov
    Jun 25, 2003
  2. Thomas Lenz
    Replies:
    7
    Views:
    373
    Jim Langston
    Oct 23, 2007
  3. Bala2508
    Replies:
    28
    Views:
    1,149
    Jim Langston
    Nov 3, 2007
  4. Fab
    Replies:
    4
    Views:
    1,395
    Thomas J. Gritzan
    Mar 24, 2008
  5. Replies:
    12
    Views:
    972
    Jerry Coffin
    Jun 2, 2008
Loading...

Share This Page