appending to ostringstream's

appending to ostringstream's

Post by Stephen How » Thu, 20 Jul 2000 04:00:00



Hello,

I have a small program:

#include <sstream>
#include <iostream>

using namespace std;

int main()
{
    ostringstream os;
    ostringstream os2(ios::app | ios::ate);
    int i = 12345;

    os.str("This is a string");
    os << i;
    cout << '[' << os.str() << ']' << endl;

    os2.str("This is a string");
    os2 << i;
    cout << '[' << os2.str() << ']' << endl;

    return 0;

Quote:}

Now the output is

[12345is a string]
[12345is a string]

The first line does not surprise me as the seek position of the associated
streambuf is at 0. The second line does surprise me. I would have thought
that because the openmode is ios::app and no longer the default of ios::out,
I would get as output

[This is a string12345]

Where have I gone wrong in my thinking?

The idea behind this is that rather than do

os.str("");
os << "This is a string" << i;

I can do

os.str("This is a string");
os << i;

and save an extra call to clear the string. Certainly it has "reset" the
underlying basic_string, but the seek position is not at the end of the
string. I would have thought that changing the openmode to append would
guarantee this.

Anybody shed light on this?

Thanks

Stephen Howe

 
 
 

appending to ostringstream's

Post by Bob Alle » Thu, 20 Jul 2000 04:00:00


the str function freezes the buffer, you need to unfreeze it to add more too
it.

Bob

Quote:> Hello,

> I have a small program:

> #include <sstream>
> #include <iostream>

> using namespace std;

> int main()
> {
>     ostringstream os;
>     ostringstream os2(ios::app | ios::ate);
>     int i = 12345;

>     os.str("This is a string");
>     os << i;
>     cout << '[' << os.str() << ']' << endl;

>     os2.str("This is a string");
>     os2 << i;
>     cout << '[' << os2.str() << ']' << endl;

>     return 0;
> }

> Now the output is

> [12345is a string]
> [12345is a string]

> The first line does not surprise me as the seek position of the associated
> streambuf is at 0. The second line does surprise me. I would have thought
> that because the openmode is ios::app and no longer the default of
ios::out,
> I would get as output

> [This is a string12345]

> Where have I gone wrong in my thinking?

> The idea behind this is that rather than do

> os.str("");
> os << "This is a string" << i;

> I can do

> os.str("This is a string");
> os << i;

> and save an extra call to clear the string. Certainly it has "reset" the
> underlying basic_string, but the seek position is not at the end of the
> string. I would have thought that changing the openmode to append would
> guarantee this.

> Anybody shed light on this?

> Thanks

> Stephen Howe


 
 
 

appending to ostringstream's

Post by Stephen How » Thu, 20 Jul 2000 04:00:00



Quote:> the str function freezes the buffer, you need to unfreeze it to add more
too
> it.

No it does not. You are thinking of ostrstream's the predecessor of ISO
C++'s ostringstream's.

What you say is perfectly correct fot ostrstream which is based on a char *
buffer. ostreamstream has a basic_string as a buffer.

Try doing

ostringstream os;

os << "here is a line" << endl;
cout << os.str();
os << "here is a second line " << endl;
cout << os.str();

You will find that the 2nd output to os will dump to cout without you having
to unfreeze. This baggage has gone with the new ISO C++ ostringstream's.

But thanks for your help Bob, I appreciate it.

Stephen Howe

 
 
 

appending to ostringstream's

Post by John Harriso » Thu, 20 Jul 2000 04:00:00



Quote:> Hello,

> I have a small program:

> #include <sstream>
> #include <iostream>

> using namespace std;

> int main()
> {
>     ostringstream os;
>     ostringstream os2(ios::app | ios::ate);
>     int i = 12345;

>     os.str("This is a string");
>     os << i;
>     cout << '[' << os.str() << ']' << endl;

>     os2.str("This is a string");
>     os2 << i;
>     cout << '[' << os2.str() << ']' << endl;

>     return 0;
> }

> Now the output is

> [12345is a string]
> [12345is a string]

> The first line does not surprise me as the seek position of the associated
> streambuf is at 0. The second line does surprise me. I would have thought
> that because the openmode is ios::app and no longer the default of
ios::out,
> I would get as output

> [This is a string12345]

> Where have I gone wrong in my thinking?

> The idea behind this is that rather than do

> os.str("");
> os << "This is a string" << i;

> I can do

> os.str("This is a string");
> os << i;

> and save an extra call to clear the string. Certainly it has "reset" the
> underlying basic_string, but the seek position is not at the end of the
> string. I would have thought that changing the openmode to append would
> guarantee this.

> Anybody shed light on this?

> Thanks

> Stephen Howe

I'm not sure that ios_base::app and ios_base::ate work for ostringstreams,
in any case str("a string") resets the stream position to the beginning of
the given string for an ostringstream.

You'd be better off writing

ostringstream oss;
oss << "a string" << 12345;

john

 
 
 

appending to ostringstream's

Post by Stephen How » Thu, 20 Jul 2000 04:00:00



Quote:> I'm not sure that ios_base::app and ios_base::ate work for ostringstreams,

They do not? This is what I have as constructors:

explicit basic_ostringstream(ios_base::openmode mode = ios_base::out);
explicit basic_ostringstream(const basic_string<E, T, A>& x,
ios_base::openmode mode = ios_base::out);

which shows that the default openmode parameter is ios_base::out. One
wonders why it is a parameter if it is of no use at all.

Quote:> in any case str("a string") resets the stream position to the beginning of
> the given string for an ostringstream.

Right. But this is where I thought specifying ios_base::app would make a
difference. After all if this was an fstream that had been opened using
ios::app and you moved the seek pointers to read from the beginning of an
existing file, writing to the file should still be at the end of the file
should it not? That is what append means.

But thanks John for responding, I appreciate it.

Stephen Howe

 
 
 

appending to ostringstream's

Post by Dietmar Kueh » Thu, 20 Jul 2000 04:00:00


Hi,


Quote:>     ostringstream os2(ios::app | ios::ate);

Only the modes 'std::ios_base::in' and 'std::ios_base::out' are used
by string streams. All other flags are ignored.

Quote:>     int i = 12345;

>     os.str("This is a string");
>     os << i;

If I remember correctly, the initial position of the write pointer
construction or resetting the string with 'str()' is not really defined
by the standard. I think my implementation positions both the read and
write position to the end of the string but I'm not sure about this.

However, to be certain where the position is, just seek to the
corresponding position:

  os.seekp(0, std::ios_base::end);

(I haven't tested this code but it should be pretty close...).
--

<http://www.dietmar-kuehl.de/>

Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

appending to ostringstream's

Post by John Harriso » Thu, 20 Jul 2000 04:00:00





> > I'm not sure that ios_base::app and ios_base::ate work for
ostringstreams,

> They do not? This is what I have as constructors:

> explicit basic_ostringstream(ios_base::openmode mode = ios_base::out);
> explicit basic_ostringstream(const basic_string<E, T, A>& x,
> ios_base::openmode mode = ios_base::out);

> which shows that the default openmode parameter is ios_base::out. One
> wonders why it is a parameter if it is of no use at all.

It would be useful for ios_base::binary

john

 
 
 

appending to ostringstream's

Post by Dietmar Kueh » Thu, 20 Jul 2000 04:00:00


Hi,




> > One wonders why it is a parameter if it is of no use at all.
> It would be useful for ios_base::binary

No. The only flags used are 'std::ios_base::in' and
'std::ios_base::out'. These flags are used to determine which buffers
have to be setup for the stream buffer. The setting of these flags
might influence the performance of the stream buffer because when
writing to to an "in/out" string stream the output buffer has to be
updated if the overall buffer available is increased.
--

<http://www.dietmar-kuehl.de/>

Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

appending to ostringstream's

Post by Stephen How » Fri, 21 Jul 2000 04:00:00



> Hi,


> >     ostringstream os2(ios::app | ios::ate);

> Only the modes 'std::ios_base::in' and 'std::ios_base::out' are used
> by string streams. All other flags are ignored.

Thanks Dietmar. Useful to know. Well that is a blow. Don't see why
std::ios_base::app can't be taken notice of. It saves an explicit call to
seekp().

Quote:> However, to be certain where the position is, just seek to the
> corresponding position:

>   os.seekp(0, std::ios_base::end);

I think you are right but it is less elegant. If you initalise str() to be
something other than an empty string, why would you then want to overwrite
it? Does not make sense. Logical position of seekp() shoudl be at the end.

Thanks again.

--
Stephen Howe

 
 
 

1. Diff b/w using ostringstream directly and using ostringstream's rdbuf()?

Dear all,

I'm using ostringstream to concat my primitive values (int, char and
double) into one whole string.

I'm wondering what is the difference between using ostringstream
directly and using ostringstream's rdbuf()?

I found that when I using ostringstream's str() in my C++ Native
methods in JNI, I would hit a JVM error. But if I use ostringstream's
rdbuf() first, then convert the string buffer to a string, the JNI
works fine.

Can someone please enlighten me...

Thanks.

regards,
Betty

2. Win95 terminal emulator and HP-UX 10.20

3. FTP 'append' using wininet

4. Teles 16.3 and PcAnywhere

5. What's wrong with ostringstream?

6. Uninstall Frontpage Extensions on Windows98SE

7. Is it possible to overload 'endl' manipulator in the derived class of ostream (or ostringstream)

8. VAX-VMS - NT admin needed

9. VC++: Seen this? Mem leak from ostringstream

10. 'initializing' : truncation from 'const double' to 'float' warning

11. Problems when write manipulator for a class derived from ostringstream

12. ostringstream perplexity

13. Problem using ostringstream str function