stringstream overwrite with constructor vs. <<

Discussion in 'C++' started by martinezfive@comcast.net, Jan 4, 2007.

  1. Guest

    Hi,
    I feel no doubt some documentation contains my answer, so bare with
    me. Given the following:

    #inclde <stdio.h>
    #include <sstream>

    void f()
    {
    std::stringstream a("Hello World!\n");
    a << "Bite me!\n";
    printf( a.str().c_str() );
    }

    I expect to see:

    Hello World!
    Bite me!

    on the console. However, I instead find:

    Bite me!
    ld!

    no matter what compiler/library combination I use. As I mentioned,
    surely, the answer to "Why?" appears somewhere, I simply remain unable
    to find it. Would someone point me in the right direction for the
    answer?
     
    , Jan 4, 2007
    #1
    1. Advertising

  2. wrote:
    > Hi,
    > I feel no doubt some documentation contains my answer, so bare with
    > me. Given the following:
    >
    > #inclde <stdio.h>
    > #include <sstream>
    >
    > void f()
    > {
    > std::stringstream a("Hello World!\n");
    > a << "Bite me!\n";
    > printf( a.str().c_str() );
    > }
    >
    > I expect to see:
    >
    > Hello World!
    > Bite me!
    >
    > on the console. However, I instead find:
    >
    > Bite me!
    > ld!
    >
    > no matter what compiler/library combination I use. As I mentioned,
    > surely, the answer to "Why?" appears somewhere, I simply remain unable
    > to find it. Would someone point me in the right direction for the
    > answer?


    I think you either need to open your stream for appending, or position
    it at its end before writing.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Jan 4, 2007
    #2
    1. Advertising

  3. Bo Persson Guest

    Victor Bazarov wrote:
    > wrote:
    >> Hi,
    >> I feel no doubt some documentation contains my answer, so bare
    >> with me. Given the following:
    >>
    >> #inclde <stdio.h>
    >> #include <sstream>
    >>
    >> void f()
    >> {
    >> std::stringstream a("Hello World!\n");
    >> a << "Bite me!\n";
    >> printf( a.str().c_str() );
    >> }
    >>
    >> I expect to see:
    >>
    >> Hello World!
    >> Bite me!
    >>
    >> on the console. However, I instead find:
    >>
    >> Bite me!
    >> ld!
    >>
    >> no matter what compiler/library combination I use. As I mentioned,
    >> surely, the answer to "Why?" appears somewhere, I simply remain
    >> unable to find it. Would someone point me in the right direction
    >> for the answer?

    >
    > I think you either need to open your stream for appending, or
    > position it at its end before writing.
    >


    Yes, a stream only has one 'current position', which is either a read
    position or a write position. When you construct a stream, it cannot know if
    the next operation will be a read or a write, so unless specifically
    instructed the 'current position' is set at the start of the stream.


    Bo Persson
     
    Bo Persson, Jan 4, 2007
    #3
  4. Guest

    Bo Persson wrote:
    > Victor Bazarov wrote:
    > > wrote:
    > >> Hi,
    > >> I feel no doubt some documentation contains my answer, so bare
    > >> with me. Given the following:
    > >>
    > >> #inclde <stdio.h>
    > >> #include <sstream>
    > >>
    > >> void f()
    > >> {
    > >> std::stringstream a("Hello World!\n");
    > >> a << "Bite me!\n";
    > >> printf( a.str().c_str() );
    > >> }
    > >>
    > >> I expect to see:
    > >>
    > >> Hello World!
    > >> Bite me!
    > >>
    > >> on the console. However, I instead find:
    > >>
    > >> Bite me!
    > >> ld!
    > >>
    > >> no matter what compiler/library combination I use. As I mentioned,
    > >> surely, the answer to "Why?" appears somewhere, I simply remain
    > >> unable to find it. Would someone point me in the right direction
    > >> for the answer?

    > >
    > > I think you either need to open your stream for appending, or
    > > position it at its end before writing.
    > >

    >
    > Yes, a stream only has one 'current position', which is either a read
    > position or a write position. When you construct a stream, it cannot know if
    > the next operation will be a read or a write, so unless specifically
    > instructed the 'current position' is set at the start of the stream.
    >
    >
    > Bo Persson


    Do you know of the particular portion of the ANSI C++ Standard to cite
    describing the 'current position' characteristic? My copy does not
    make such a statement, as best I can tell.
     
    , Jan 4, 2007
    #4
  5. wrote:
    > [..]
    > Do you know of the particular portion of the ANSI C++ Standard to cite
    > describing the 'current position' characteristic? My copy does not
    > make such a statement, as best I can tell.


    I am not sure what to cite except the whole of clause 27. The Standard
    document is not an instruction manual from which you can learn how to
    program. You will be much better off with a good book.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Jan 4, 2007
    #5
  6. BobR Guest

    wrote in message ...
    >
    >Do you know of the particular portion of the ANSI C++ Standard to cite
    >describing the 'current position' characteristic? My copy does not
    >make such a statement, as best I can tell.
    >


    No, I don't. But this works for me:

    {
    std::stringstream ass("Hello World!\n");
    ass.seekp(0, std::ios_base::end);
    ass << "Bite me!\n";
    // printf( ass.str().c_str() );
    cout<<" stringstream ass test ="<<ass.str().c_str()<<std::endl;
    }
    /* - output -
    stringstream ass test =Hello World!
    Bite me!
    */

    --
    Bob R
    POVrookie
     
    BobR, Jan 4, 2007
    #6
  7. Guest

    Victor Bazarov wrote:
    > wrote:
    > > [..]
    > > Do you know of the particular portion of the ANSI C++ Standard to cite
    > > describing the 'current position' characteristic? My copy does not
    > > make such a statement, as best I can tell.

    >
    > I am not sure what to cite except the whole of clause 27. The Standard
    > document is not an instruction manual from which you can learn how to
    > program. You will be much better off with a good book.
    >
    > V
    > --
    > Please remove capital 'A's when replying by e-mail
    > I do not respond to top-posted replies, please don't ask


    I agree a good book provides better instruction on learning to program.
    However, in my line of work, I need to know the ins and outs of the
    Standard Library, prompting my concern with the ANSI Standard.

    Looking through Clause 27, we see the '<<' *should* insert the argument
    on the RHS into the one on the LHS. The fact the constructor
    initializes the stringstream's internal buffer leads me to expect the
    subsequent '<<' will append (not overwrite) the RHS to the buffer of
    the stringstream. However, after checking Borland, Edison Design
    Group, GCC, and MS 6, 7 and 8 (all six in both strict and non-strict
    modes), I found each one of these compilers and their Standard Library
    implementations produce the (from my POV) non-intuitive behavior.

    As I said, I feel confident the rationale for this output exists
    *somewhere*. However, I have not found it in the documentation of any
    of my compilers or their libraries, leaving me with my original
    question: Why?
     
    , Jan 4, 2007
    #7
  8. wrote:
    > [..]
    > Looking through Clause 27, we see the '<<' *should* insert the
    > argument on the RHS into the one on the LHS.


    It does. At the predefined location in the buffer. Here, the
    location is the beginning of the buffer, not its end.

    > The fact the constructor
    > initializes the stringstream's internal buffer leads me to expect the
    > subsequent '<<' will append (not overwrite) the RHS to the buffer of
    > the stringstream.


    Why? "Insert" doesn't mean "append".

    > However, after checking Borland, Edison Design
    > Group, GCC, and MS 6, 7 and 8 (all six in both strict and non-strict
    > modes), I found each one of these compilers and their Standard Library
    > implementations produce the (from my POV) non-intuitive behavior.


    It cannot be [non-]intuitive from anybody's single POV. It's either
    intuitive or not, meaning that the majority of sapient beings expect
    it to behave in a certain manner.

    > As I said, I feel confident the rationale for this output exists
    > *somewhere*. However, I have not found it in the documentation of any
    > of my compilers or their libraries, leaving me with my original
    > question: Why?


    Trace all explanations from the 'operator<<' to 'sputc'. Start in
    27.6.2.5.4. 27.6.2 is where 'sputc' is mentioned. It's not easy,
    I give you that. Reading the Standard is not for impatient. That's
    why a good book helps, and hopefully mentions the Standard as well.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Jan 5, 2007
    #8
  9. BobR Guest

    wrote in message ...
    >
    >Looking through Clause 27, we see the '<<' *should* insert the argument
    >on the RHS into the one on the LHS. The fact the constructor
    >initializes the stringstream's internal buffer leads me to expect the
    >subsequent '<<' will append (not overwrite) the RHS to the buffer of
    >the stringstream.


    {
    std::stringstream ass("Hello World!\n");
    std::cout<<" ass test tellp="<<ass.tellp()<<std::endl;
    std::cout<<" ass test tellg="<<ass.tellg()<<std::endl;
    }

    You'll see that the stream is initialised with the 'get' and 'put' pointers
    set to zero.


    > However, after checking Borland, Edison Design
    >Group, GCC, and MS 6, 7 and 8 (all six in both strict and non-strict
    >modes), I found each one of these compilers and their Standard Library
    >implementations produce the (from my POV) non-intuitive behavior.


    I think it is reasonable.

    >
    >As I said, I feel confident the rationale for this output exists
    >*somewhere*. However, I have not found it in the documentation of any
    >of my compilers or their libraries, leaving me with my original
    >question: Why?
    >


    If you want to 'Append To End' (ate), tell the stream that!

    {
    std::stringstream ass( "Hello World!\n", std::ios::eek:ut |
    std::ios::ate );

    std::cout<<" ass test tellp="<<ass.tellp()<<std::endl;
    // std::cout<<" ass test tellg="<<ass.tellg()<<std::endl;
    // ass.seekp(0, std::ios_base::end);
    ass << "Bite me!\n";
    // printf( ass.str().c_str() );
    std::cout<<" stringstream ass test ="<<ass.str().c_str()<<std::endl;
    }

    If you use 'std::ios::app', you can't re-position the ostream pointer, it
    will always return to the end.

    --
    Bob R
    POVrookie
     
    BobR, Jan 5, 2007
    #9
  10. Bo Persson Guest

    wrote:
    > Bo Persson wrote:
    >> Victor Bazarov wrote:
    >>> wrote:
    >>>> Hi,
    >>>> I feel no doubt some documentation contains my answer, so bare
    >>>> with me. Given the following:
    >>>>
    >>>> #inclde <stdio.h>
    >>>> #include <sstream>
    >>>>
    >>>> void f()
    >>>> {
    >>>> std::stringstream a("Hello World!\n");
    >>>> a << "Bite me!\n";
    >>>> printf( a.str().c_str() );
    >>>> }
    >>>>
    >>>> I expect to see:
    >>>>
    >>>> Hello World!
    >>>> Bite me!
    >>>>
    >>>> on the console. However, I instead find:
    >>>>
    >>>> Bite me!
    >>>> ld!
    >>>>
    >>>> no matter what compiler/library combination I use. As I
    >>>> mentioned, surely, the answer to "Why?" appears somewhere, I
    >>>> simply remain unable to find it. Would someone point me in the
    >>>> right direction for the answer?
    >>>
    >>> I think you either need to open your stream for appending, or
    >>> position it at its end before writing.
    >>>

    >>
    >> Yes, a stream only has one 'current position', which is either a
    >> read position or a write position. When you construct a stream, it
    >> cannot know if the next operation will be a read or a write, so
    >> unless specifically instructed the 'current position' is set at
    >> the start of the stream.
    >>
    >>
    >> Bo Persson

    >
    > Do you know of the particular portion of the ANSI C++ Standard to
    > cite describing the 'current position' characteristic? My copy
    > does not make such a statement, as best I can tell.


    The formal term is actually "the stream position", given in section 27.5.1
    on Stream buffer requirements.

    Section 27.7.1.1 describes the constructors for basic_stringbuf, which holds
    the content of a stringstream. It says:

    "explicit basic_stringbuf(const basic_string<charT,traits,Allocator>& str ,
    ios_base::eek:penmode which = ios_base::in |
    ios_base::eek:ut);

    Effects: Constructs an object of class basic_stringbuf, initializing the
    base class with basic_streambuf() (27.5.2.1), and initializing mode with
    which . Then copies the content of str into the basic_stringbuf underlying
    character sequence. If which & ios_base::eek:ut is true, initializes the output
    sequence such that pbase() points to the first underlying character, epptr()
    points one past the last underlying character, and pptr() is equal to
    epptr() if which & ios_base::ate is true, otherwise pptr() is equal to
    pbase(). If which & ios_base::in is true, initializes the input sequence
    such that eback() and gptr() point to the first underlying character and
    egptr() points one past the last underlying character."


    Here pptr() is the "put pointer" indicating the next position to write.
    Default is to have pptr() and gptr() start at the beginning of the buffer.



    Bo Persson
     
    Bo Persson, Jan 5, 2007
    #10
    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. =?Utf-8?B?Um9iZXJ0?=

    Deployment in 2.0 - How To Not Overwrite web.config

    =?Utf-8?B?Um9iZXJ0?=, Nov 2, 2005, in forum: ASP .Net
    Replies:
    8
    Views:
    4,462
    Juan T. Llibre
    Nov 3, 2005
  2. VisionSet
    Replies:
    1
    Views:
    4,174
    Adam Lipscombe
    Sep 2, 2003
  3. Philipp Leitner

    Overwrite Default Constructor ?

    Philipp Leitner, Apr 17, 2006, in forum: Java
    Replies:
    26
    Views:
    4,403
    Jeroen V.
    Apr 19, 2006
  4. Generic Usenet Account
    Replies:
    10
    Views:
    2,245
  5. Mug

    constructor overwrite

    Mug, Feb 15, 2010, in forum: Python
    Replies:
    3
    Views:
    362
    Bruno Desthuilliers
    Feb 15, 2010
Loading...

Share This Page