STL and aCC

T

Torsten Mueller

I have a problem using the native STL implementation (this is a Rogue
Wave one) with the aCC compiler (HP ANSI C++ B3810B A.03.55) on HPUX
11. Yes, it's old. But why it does not work?

My program looks like this:

int main (int argc,char* argv[])
{
cout << endl;
return 0;
}

It crashes during the stream output operation. The stack is as
follows:

#0 0x77fa5368 in kill () from /usr/lib/libc.2
#1 0x77f42280 in raise () from /usr/lib/libc.2
#2 0x77f8291c in abort_C () from /usr/lib/libc.2
#3 0x77f82974 in abort () from /usr/lib/libc.2
#4 0x77d6483c in std::terminate () from /usr/lib/libCsup_v2.2
#5 0x77d647dc in std::terminate () from /usr/lib/libCsup_v2.2
#6 0x77d64cf4 in ThrowException () from /usr/lib/libCsup_v2.2
#7 0x77d65254 in __throw__FPvT1 () from /usr/lib/libCsup_v2.2
#8 0x77cced0c in std::locale::_C_install_facet () from /usr/lib/libstd_v2.2
#9 0x77cce92c in std::locale::_C_make_facet () from /usr/lib/libstd_v2.2
#10 0x000d8ea4 in std::basic_filebuf<char,std::char_traits<char>>::eek:verflow
(this=0x77b5b550, __c=-1) at /opt/aCC/include_std/fstream.cc:339
#11 0x000d9778 in std::basic_filebuf<char,std::char_traits<char>>::sync
(this=0x77b5b550) at /opt/aCC/include_std/fstream.cc:572
#12 (here is main)

What's the reason for this exception? Can I something do to avoid
this? The STLPort library I use before does not show this problem.

T.M.
 
T

Thomas Maier-Komor

Torsten said:
I have a problem using the native STL implementation (this is a Rogue
Wave one) with the aCC compiler (HP ANSI C++ B3810B A.03.55) on HPUX
11. Yes, it's old. But why it does not work?

My program looks like this:

int main (int argc,char* argv[])
{
cout << endl;
return 0;
}

It crashes during the stream output operation. The stack is as
follows:

#0 0x77fa5368 in kill () from /usr/lib/libc.2
#1 0x77f42280 in raise () from /usr/lib/libc.2
#2 0x77f8291c in abort_C () from /usr/lib/libc.2
#3 0x77f82974 in abort () from /usr/lib/libc.2
#4 0x77d6483c in std::terminate () from /usr/lib/libCsup_v2.2
#5 0x77d647dc in std::terminate () from /usr/lib/libCsup_v2.2
#6 0x77d64cf4 in ThrowException () from /usr/lib/libCsup_v2.2
#7 0x77d65254 in __throw__FPvT1 () from /usr/lib/libCsup_v2.2
#8 0x77cced0c in std::locale::_C_install_facet () from /usr/lib/libstd_v2.2
#9 0x77cce92c in std::locale::_C_make_facet () from /usr/lib/libstd_v2.2
#10 0x000d8ea4 in std::basic_filebuf<char,std::char_traits<char>>::eek:verflow
(this=0x77b5b550, __c=-1) at /opt/aCC/include_std/fstream.cc:339
#11 0x000d9778 in std::basic_filebuf<char,std::char_traits<char>>::sync
(this=0x77b5b550) at /opt/aCC/include_std/fstream.cc:572
#12 (here is main)

What's the reason for this exception? Can I something do to avoid
this? The STLPort library I use before does not show this problem.

T.M.
Click to expand...

looks like a bug in the STL lib to me. Assuming you #include'd
<iostream> and setup the namespace std correctly (which you omitted in
your code snipped), I cannot see anything wrong. But omitting the header
file might result in a source file that can be compiled correctly, but
shows broken behavior when executed.

Tom
 
T

Torsten Mueller

Thomas Maier-Komor said:
Assuming you #include'd <iostream> and setup the namespace std
correctly (which you omitted in your code snipped),
Click to expand...

Sure, I use the following lines:

namespace std {}
using namespace std;

#include <iostream>

(I declare the namespace first because of some C++ compilers (for
example MSVC) have own older stream class implementations additional
to the STL classes and declaring the namespace first ensures the use
of the real STL classes.)

I have not a single warning during the compile and link processes.

T.M.
 
?

=?iso-8859-1?q?Stephan_Br=F6nnimann?=

Torsten said:
I have a problem using the native STL implementation (this is a Rogue
Wave one) with the aCC compiler (HP ANSI C++ B3810B A.03.55) on HPUX
11. Yes, it's old. But why it does not work?

My program looks like this:

int main (int argc,char* argv[])
{
cout << endl;
return 0;
}

It crashes during the stream output operation. The stack is as
follows:

#0 0x77fa5368 in kill () from /usr/lib/libc.2
#1 0x77f42280 in raise () from /usr/lib/libc.2
#2 0x77f8291c in abort_C () from /usr/lib/libc.2
#3 0x77f82974 in abort () from /usr/lib/libc.2
#4 0x77d6483c in std::terminate () from /usr/lib/libCsup_v2.2
#5 0x77d647dc in std::terminate () from /usr/lib/libCsup_v2.2
#6 0x77d64cf4 in ThrowException () from /usr/lib/libCsup_v2.2
#7 0x77d65254 in __throw__FPvT1 () from /usr/lib/libCsup_v2.2
#8 0x77cced0c in std::locale::_C_install_facet () from /usr/lib/libstd_v2.2
#9 0x77cce92c in std::locale::_C_make_facet () from /usr/lib/libstd_v2.2
#10 0x000d8ea4 in std::basic_filebuf<char,std::char_traits<char>>::eek:verflow
(this=0x77b5b550, __c=-1) at /opt/aCC/include_std/fstream.cc:339
#11 0x000d9778 in std::basic_filebuf<char,std::char_traits<char>>::sync
(this=0x77b5b550) at /opt/aCC/include_std/fstream.cc:572
#12 (here is main)

What's the reason for this exception? Can I something do to avoid
this? The STLPort library I use before does not show this problem.

T.M.
Click to expand...

Such unexpected behaviour might be caused by imcompatible libraries.
I've experienced this when I changed the definition of a class but did
not recompile all dependend implementation files.
In my case the application crash when calling a member function taken a
const std::string& argument.

Regards, Stephan
 
M

Marcus Kwok

Torsten Mueller said:
Sure, I use the following lines:

namespace std {}
using namespace std;

#include <iostream>

(I declare the namespace first because of some C++ compilers (for
example MSVC) have own older stream class implementations additional
to the STL classes and declaring the namespace first ensures the use
of the real STL classes.)

I have not a single warning during the compile and link processes.
Click to expand...

Try also #include'ing <ostream> (for std::endl).
 
T

Torsten Mueller

Try also #include'ing <ostream> (for std::endl).
Click to expand...

<ostream> is included by <iostream>. endl is known.

I think about a problem of initializing the cout object.

T.M.
 
M

Marcus Kwok

Torsten Mueller said:
<ostream> is included by <iostream>. endl is known.
Click to expand...

OK. I remember having to explicitly #include <ostream> to get std::endl
using aCC (don't remember the version or library vendor though).
However, it gave me compile errors, which you said you did not. Sorry,
I have no further ideas on this issue.
 
N

Nathanael Hoyle

I have a problem using the native STL implementation (this is a Rogue
Wave one) with the aCC compiler (HP ANSI C++ B3810B A.03.55) on HPUX
11. Yes, it's old. But why it does not work?

My program looks like this:

int main (int argc,char* argv[])
{
cout << endl;
return 0;
}

It crashes during the stream output operation. The stack is as
follows:

#0 0x77fa5368 in kill () from /usr/lib/libc.2
#1 0x77f42280 in raise () from /usr/lib/libc.2
#2 0x77f8291c in abort_C () from /usr/lib/libc.2
#3 0x77f82974 in abort () from /usr/lib/libc.2
#4 0x77d6483c in std::terminate () from /usr/lib/libCsup_v2.2
#5 0x77d647dc in std::terminate () from /usr/lib/libCsup_v2.2
#6 0x77d64cf4 in ThrowException () from /usr/lib/libCsup_v2.2
#7 0x77d65254 in __throw__FPvT1 () from /usr/lib/libCsup_v2.2
#8 0x77cced0c in std::locale::_C_install_facet () from /usr/lib/libstd_v2.2
#9 0x77cce92c in std::locale::_C_make_facet () from /usr/lib/libstd_v2.2
#10 0x000d8ea4 in std::basic_filebuf<char,std::char_traits<char>>::eek:verflow
(this=0x77b5b550, __c=-1) at /opt/aCC/include_std/fstream.cc:339
#11 0x000d9778 in std::basic_filebuf<char,std::char_traits<char>>::sync
(this=0x77b5b550) at /opt/aCC/include_std/fstream.cc:572
#12 (here is main)

What's the reason for this exception? Can I something do to avoid
this? The STLPort library I use before does not show this problem.

T.M.
Click to expand...

Please post the full file you're using (I presume that there are header
#include's for at least <ostream>, since you're using the ostream
library...), as well as any compile output, with all warning options
enabled. The last time I used the RW STL was in 2000, on Solaris 2.5.1
and 2.7 (7)... I was not impressed with it then. But without more
information here, I can't see what's wrong. Aside from the fact that you
appear to have omitted a #include and a 'using namespsace std;' directive,
this looks correct, and the stack trace seems to indicate some sort of
overflow. I'm not sure, reading the trace there, but check and see if RW
might be sensitive to the locale settings for the system (since you didn't
specify one), and it may have no sensible default. RW never was very
sensible...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Compile error on templated STL map class 3
problems about aCC 3
Diffrerent output of the same program on HP aCC and Linux (Intel/g++) 2
aCC : error 2265 - type is inaccessible 0
linux g++ compile error 1
libs compilation 2
string close causes SIGSEGV 3
Compiling with aCC on 64 bit HPUX 0

Members online

No members online now.
Total: 33 (members: 0, guests: 33)
Robots: 417

Forum statistics

Threads
473,768
Messages
2,569,575
Members
45,053
Latest member
billing-software

Latest Threads

Top