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?

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

Victor Bazarov wrote:

martinezfive@comcast.net wrote:

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

Victor Bazarov wrote:

>
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.

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

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

Victor Bazarov wrote:

martinezfive@comcast.net wrote:

>
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?

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

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

martinezfive@comcast.net wrote:

Bo Persson 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.

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