STL and aCC

[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_file buf<char,std::c har_traits<char >>::overflow
(this=0x77b5b55 0, __c=-1) at /opt/aCC/include_std/fstream.cc:339
#11 0x000d9778 in std::basic_file buf<char,std::c har_traits<char >>::sync
(this=0x77b5b55 0) 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.

[Thomas Maier-Komor]

Re: STL and aCC

Torsten Mueller wrote:[color=blue]
> 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_file buf<char,std::c har_traits<char >>::overflow
> (this=0x77b5b55 0, __c=-1) at /opt/aCC/include_std/fstream.cc:339
> #11 0x000d9778 in std::basic_file buf<char,std::c har_traits<char >>::sync
> (this=0x77b5b55 0) 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.[/color]

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

[Torsten Mueller]

Re: STL and aCC

Thomas Maier-Komor <maierkom@lpr .e-technik.no-spam.tu-muenchen.de> schrieb:
[color=blue]
> Assuming you #include'd <iostream> and setup the namespace std
> correctly (which you omitted in your code snipped),[/color]

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.

[Stephan Brönnimann]

Re: STL and aCC

Torsten Mueller wrote:[color=blue]
> 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_file buf<char,std::c har_traits<char >>::overflow
> (this=0x77b5b55 0, __c=-1) at /opt/aCC/include_std/fstream.cc:339
> #11 0x000d9778 in std::basic_file buf<char,std::c har_traits<char >>::sync
> (this=0x77b5b55 0) 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.[/color]

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

[Marcus Kwok]

Re: STL and aCC

Torsten Mueller <dev-null@shared-files.de> wrote:[color=blue]
> Thomas Maier-Komor <maierkom@lpr .e-technik.no-spam.tu-muenchen.de> schrieb:
>[color=green]
>> Assuming you #include'd <iostream> and setup the namespace std
>> correctly (which you omitted in your code snipped),[/color]
>
> 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.[/color]

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

--
Marcus Kwok

[Torsten Mueller]

Re: STL and aCC

ricecake@gehenn om.net (Marcus Kwok) schrieb:
[color=blue][color=green]
> > I have not a single warning during the compile and link processes.[/color]
>
> Try also #include'ing <ostream> (for std::endl).[/color]

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

I think about a problem of initializing the cout object.

T.M.

[Marcus Kwok]

Re: STL and aCC

Torsten Mueller <dev-null@shared-files.de> wrote:[color=blue]
> ricecake@gehenn om.net (Marcus Kwok) schrieb:
>[color=green][color=darkred]
>> > I have not a single warning during the compile and link processes.[/color]
>>
>> Try also #include'ing <ostream> (for std::endl).[/color]
>
> <ostream> is included by <iostream>. endl is known.[/color]

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.
[color=blue]
> I think about a problem of initializing the cout object.[/color]

--
Marcus Kwok

[Mike Wahler]

Re: STL and aCC


"Torsten Mueller" <dev-null@shared-files.de> wrote in message
news:ubqy6syib. fsf@fastmail.fm ...[color=blue]
> ricecake@gehenn om.net (Marcus Kwok) schrieb:
>[color=green][color=darkred]
>> > I have not a single warning during the compile and link processes.[/color]
>>
>> Try also #include'ing <ostream> (for std::endl).[/color]
>
> <ostream> is[/color]

not required to be
[color=blue]
> included by <iostream>.[/color]
[color=blue]
> endl is[/color]

only guaranteed to be
[color=blue]
> known.[/color]

in scope if <ostream> is included.
[color=blue]
>
> I think about a problem of initializing the cout object.[/color]

What problem?

-Mike

[Nathanael Hoyle]

Re: STL and aCC

On Fri, 20 Jan 2006 10:27:13 +0100, Torsten Mueller wrote:
[color=blue]
> 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_file buf<char,std::c har_traits<char >>::overflow
> (this=0x77b5b55 0, __c=-1) at /opt/aCC/include_std/fstream.cc:339
> #11 0x000d9778 in std::basic_file buf<char,std::c har_traits<char >>::sync
> (this=0x77b5b55 0) 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.[/color]

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