stringstream overwrite with constructor vs. <<
 

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?

Re: stringstream overwrite with constructor vs. <<
 

martinezfive@comcast.net 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

Re: stringstream overwrite with constructor vs. <<
 

Victor Bazarov wrote:
> martinezfive@comcast.net 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

Re: stringstream overwrite with constructor vs. <<
 

Bo Persson wrote:
> Victor Bazarov wrote:
> > martinezfive@comcast.net 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.

Re: stringstream overwrite with constructor vs. <<
 

martinezfive@comcast.net 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

Re: stringstream overwrite with constructor vs. <<
 

martinezfive@comcast.net 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

Re: stringstream overwrite with constructor vs. <<
 

Victor Bazarov wrote:
> martinezfive@comcast.net 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?

Re: stringstream overwrite with constructor vs. <<
 

martinezfive@comcast.net 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

Re: stringstream overwrite with constructor vs. <<
 

martinezfive@comcast.net 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::out |
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

Re: stringstream overwrite with constructor vs. <<
 

martinezfive@comcast.net wrote:
> Bo Persson wrote:
>> Victor Bazarov wrote:
>>> martinezfive@comcast.net 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::openmode which = ios_base::in |
ios_base::out);

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::out 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