stringstream strange output

[drusakov]

consider the following piece of code, compiled with g++ 3.4 and
stlport 5.1 on Linux 64 bit (problem persists in 32 bit too)

std::stringstream ss;
int ii = 123;
ss << "test1";
std::cout<<ss.str()<<std::endl;
ss << ii << "test2";
std::cout << ss.str()<<std::endl;

The output I'm getting is quite strange:
test1
test1test2

It like 'ii' is not printed. If I remove line #4, then all is fine and
I get "test1123test2" also if to replace 'ii' in line 5 with some
string, like "test22", you'll get last line "test1test22test2" as
expected.

drives me crazy. any idea what it can be?

Thanks,
Dmitry

 

[James Kanze]

consider the following piece of code, compiled with g++ 3.4
and stlport 5.1 on Linux 64 bit (problem persists in 32 bit
too)

Just a question: why? G++ has one of the better library
implementations around, the STL port is one of the worst. So
why use it with g++?

std::stringstream ss;
int ii = 123;
ss << "test1";
std::cout<<ss.str()<<std::endl;
ss << ii << "test2";
std::cout << ss.str()<<std::endl;

The output I'm getting is quite strange:
test1
test1test2

It like 'ii' is not printed. If I remove line #4, then all is fine and
I get "test1123test2" also if to replace 'ii' in line 5 with some
string, like "test22", you'll get last line "test1test22test2" as
expected.

drives me crazy. any idea what it can be?

It would seem to be a bug in the STL. The above code works with
the default libraries with g++, Sun CC and VC++; I get the same
symptoms as you with Sun CC and the STL port, however.

 

[drusakov]

Hi James, Jeff, and comp.lang.c++ community,

we write one very high-performance application and stlport was one of
the things recommended by other people (including other group here, at
our workplace) to boost its performance. I actually beleive the 'bug'
is a less of stlport bug, but rather something in the way we compile
and build the project, like order of linked libraries etc. I'm not
very heavy into this stuff, so it is all rather guessing, our typical
compilation line looks like: g++ -O3 -Wall -Woverloaded-virtual -
Wpointer-arith -Wwrite-strings -fomit-frame-pointer -pipe -fexceptions
-fpic -D_PTHREADS -D_REENTRANT.

As we reverted the changes back yesterday late night and given the
(permanent) time pressures, it is now impractical to recreate the
exact conditions again to investigate. Just want to see if someone on
the net came across something similar and can pin point the cause.

James - interesting opinion re stlport. We were under impression that
everyone recommends it for performance improvement.

Thanks,
Dmitry

 

[James Kanze]

we write one very high-performance application and stlport was
one of the things recommended by other people (including other
group here, at our workplace) to boost its performance.

Compared to what? In the past, a number of people have
recommended STL port, mostly, I suspect, because it was GPL, and
they believed in GPL, but partially, perhaps, because many
library implementations were of bad quality. With Sun CC, even
today, you have a choice between Rogue Wave and STL Port: with
the versions delivered with Sun CC, the quality of both is
pretty bad, and the Rogue Wave library also has some very
serious performance problems---if you have a high-performance
application and are compiling with Sun CC, you probably should
use STL port. Otherwise, however, I don't think so.

I actually beleive the 'bug' is a less of stlport bug, but
rather something in the way we compile and build the project,
like order of linked libraries etc.

I don't think so. I made a quick test, and got exactly the same
symptoms with Sun CC. So it's almost certainly an error in the
library.

I'm not very heavy into this stuff, so it is all rather
guessing, our typical compilation line looks like: g++ -O3
-Wall -Woverloaded-virtual - Wpointer-arith -Wwrite-strings
-fomit-frame-pointer -pipe -fexceptions -fpic -D_PTHREADS
-D_REENTRANT.

As we reverted the changes back yesterday late night and given
the (permanent) time pressures, it is now impractical to
recreate the exact conditions again to investigate. Just want
to see if someone on the net came across something similar and
can pin point the cause.

James - interesting opinion re stlport. We were under
impression that everyone recommends it for performance
improvement.

It's recommended for performance improvement if you are using
Sun CC; file IO, in particular, is significantly faster.
Otherwise, no. The quality is not very good, at least not in
the version which comes with Sun CC. If you're using g++, just
use the library that comes with it.

That's good advice in general, and always has been. Unless
there is a very strong reason for doing otherwise, stick with
the library which came with your compiler.