Topic: Unix and the ISO/IEC 14882-1998 Standard C++ Library
Author: Dietmar Kuehl <dietmar.kuehl@claas-solutions.de>
Date: 1999/09/08 Raw View
Hi,
In article <7r2ntv$76t$1@nnrp1.deja.com>,
James.Kanze@dresdner-bank.com wrote:
> > "Robert DiFalco" <rdifalco@tripwiresecurity.com> writes:
> > > I am totally open to choices like GNU/OSF but using these for
> > > commercial projects is very new to me. The last I looked, the GNU
> > > C++ libraries didn't look like the 14882-1998 standard libraries,
> > > especially regarding NTMBS, NTWCS, locales, and facets. However, I
> > > would love to support these efforts by using them if there is a
> > > compliant implementation that will compiler with KAI and work with
> > > NT, SGI, Linux, Solaris/Intel, HPUX, and AIX.
>
> Well, one way of supporting them would be to implement it yourself,
> then
> donate the results to the cause:-). Seriously, getting some one to
> implement it for you on contract might be your best bet. (I'd love
> such
> a contract, but I'm not free at present:-(.)
Here is another approach how to support such an implementation: I'm
mostly done although I have to admit that most of the missing stuff is
indeed in the locales area. That is, I have currently only implemented
those facets which are necessary to get IOStreams up and running. Also,
I have not yet implemented the '_byname' classes. Other than this, you
can a free implementation from <http://www.claas-solutions.de/cxxrt/>.
I'm open to support contracts to complete missing features in a timely
fashion, to remove bugs, and, of course, to help with using the C++
standard library. Currently, I support gcc-2.95 on Linux but the library
compiles on Solaris (using the same compiler), too. However, not all of
my test cases are successful (the testsuite is part of the
distribution). I'm mainly working on porting the stuff to MSVC++ 6.0
which is mostly done (a few files cannot be compiled due to missing C++
features in MSVC++ 6.0) but the code is not in namespace 'std' because
this would conflict with the implementation shipping with this
compiler (I think I can remove the conflicts but I haven't worked on
this yet).
You might want to contact Matt Austern concerning the SGI implementation
of the standard C++ library which is supposed to be also freely
available. I'm not sure whether the SGI implementation is already
available to the public. I know that this implementation is pretty
complete.
--
<mailto:dietmar.kuehl@claas-solutions.de>
homepage: <http://www.informatik.uni-konstanz.de/~kuehl>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Robert DiFalco" <rdifalco@tripwiresecurity.com>
Date: 1999/09/06 Raw View
This is a multi-part message in MIME format.
------=_NextPart_000_0016_01BEF7A7.37DBBFA0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hmm...
We are working on a project that has targets for Windoze NT, Linux, AIX, =
HPUX, SGI, and Solaris that must support multiple native locales, =
well... at least Japan (SJIS) and US/English.
We are currently using KAI with its OEM'd Standard C++ Library (Modena I =
think) for all the Unix platforms we support and MSVC++ with its OEM'd =
Standard C++ Library, DinkumWare, for Windows NT/2000. Support the =
various 14882-1998, locale, and system support between the various =
compiler versions and platforms has been more of a nightmare than, IMHO, =
it should be.
I'm particularly having a hard time with KAI, or at least with its =
Standard C++ Libraries. Apparently, while it does support the ANSI-C =
notion of wchar_t, it has no support for the STDCPP wchar_t classes such =
as the all-important std::char_traits<wchar_t>, wstring, wiostream, etc. =
As if this weren't enough, on almost all platforms KAI supports it =
apparently has no support for mbstate_t. Finally, it seems that the only =
locale that any facet are implemented for is the "classic" locale, or =
"C" locale. Even some of those seem to be broken, basically, =
std::get_facet() doesn't work.
I'd like some input regarding the following options:
A) Use a single version of a single Vendors Standard C++ Library on =
every Platform including Windows NT. Unfortunately, what is offered by =
many companies (such as Rogue-Wave and ObjectSpace) is more like the =
Standard Template Library than the Standard C++ Library.
B) Find a standard C++ library that has *complete* 14882-1998 =
support, or at least as complete as Plaguers Dinkumware Standard C++ =
Library that will work with all the platforms KAI supports, specifically =
HPUX, Redhat, SGI, AIX, and Solaris/Intel.
C) Or, if there is no other choice, replace KAI with a compiler that =
has OEM'd runtimes that do have 14882-1998 compliance sufficient enough =
to create standardized international, multiplatform C++ programs.
I am totally open to choices like GNU/OSF but using these for commercial =
projects is very new to me. The last I looked, the GNU C++ libraries =
didn't look like the 14882-1998 standard libraries, especially regarding =
NTMBS, NTWCS, locales, and facets. However, I would love to support =
these efforts by using them if there is a compliant implementation that =
will compiler with KAI and work with NT, SGI, Linux, Solaris/Intel, =
HPUX, and AIX.
Thanks in advance for your help and please excuse the naivet=E9 of my =
post.
--=20
Robert DiFalco
Development Lead
Tripwire Security Systems
------=_NextPart_000_0016_01BEF7A7.37DBBFA0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#dcdccf>
<DIV><FONT color=3D#000000 face=3D"Andale Mono">Hmm...</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=3D#000000 face=3D"Andale Mono">We are working on a =
project that has=20
targets for Windoze NT, Linux, AIX, HPUX, SGI, and Solaris that must =
support=20
multiple native locales, well... at least Japan (SJIS) and=20
US/English.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=3D#000000 face=3D"Andale Mono">We are currently using =
KAI with its=20
OEM'd Standard C++ Library (Modena I think) for all the Unix platforms =
we=20
support and MSVC++ with its OEM'd Standard C++ Library, DinkumWare, for =
Windows=20
NT/2000. Support the various 14882-1998, locale, and system support =
between the=20
various compiler versions and platforms has been more of a nightmare =
than, IMHO,=20
it should be.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=3D#000000 face=3D"Andale Mono">I'm particularly having =
a hard time=20
with KAI, or at least with its Standard C++ Libraries. Apparently, while =
it does=20
support the ANSI-C notion of wchar_t, it has no support for the STDCPP =
wchar_t=20
classes such as the all-important std::char_traits<wchar_t>, =
wstring,=20
wiostream, etc. As if this weren't enough, on almost all platforms KAI =
supports=20
it apparently has no support for mbstate_t. Finally, it seems that the =
only=20
locale that any facet are implemented for is the "classic" locale, or =
"C"=20
locale. Even some of those seem to be broken, basically, =
std::get_facet()=20
doesn't work.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=3D#000000 face=3D"Andale Mono">I'd like some input =
regarding the=20
following options:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=3D#000000 face=3D"Andale Mono"> A) =
Use a single=20
version of a single Vendors Standard C++ Library on every Platform =
including=20
Windows NT. Unfortunately, what is offered by many companies (such as =
Rogue-Wave=20
and ObjectSpace) is more like the Standard Template Library than =
the=20
Standard C++ Library.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=3D#000000 face=3D"Andale Mono"> B) =
Find a=20
standard C++ library that has *complete* 14882-1998 support, or at least =
as=20
complete as Plaguers Dinkumware Standard C++ Library that will work with =
all the=20
platforms KAI supports, specifically HPUX, Redhat, SGI, AIX, and=20
Solaris/Intel.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=3D#000000 face=3D"Andale Mono"> C) =
Or, if there=20
is no other choice, replace KAI with a compiler that has OEM'd runtimes =
that do=20
have 14882-1998 compliance sufficient enough to create standardized=20
international, multiplatform C++ programs.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=3D#000000 face=3D"Andale Mono">I am totally open to =
choices like=20
GNU/OSF but using these for commercial projects is very new to me. =
The last=20
I looked, the GNU C++ libraries didn't look like the 14882-1998 standard =
libraries, especially regarding NTMBS, NTWCS, locales, and facets. =
However, I=20
would love to support these efforts by using them if there is a =
compliant=20
implementation that will compiler with KAI and work with NT, SGI, =
Linux,=20
Solaris/Intel, HPUX, and AIX.</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT color=3D#000000 face=3D"Andale Mono">Thanks in advance for =
your help and=20
please excuse the naivet=E9 of my post.</FONT></DIV>
<DIV><FONT color=3D#000000 face=3D"Andale Mono"><BR>-- <BR>Robert=20
DiFalco<BR>Development Lead<BR>Tripwire Security=20
Systems</FONT></DIV></BODY></HTML>
------=_NextPart_000_0016_01BEF7A7.37DBBFA0--
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: Johan Kullstam <kullstam@ne.mediaone.net>
Date: 1999/09/06 Raw View
"Robert DiFalco" <rdifalco@tripwiresecurity.com> writes:
> Hmm...
i am having a particularly hard time with your lack of line breaking.
please use a newline once the line reaches 70 or so chars.
> We are working on a project that has targets for Windoze NT, Linux,
> AIX, HPUX, SGI, and Solaris that must support multiple native
> locales, well... at least Japan (SJIS) and US/English.
>
> We are currently using KAI with its OEM'd Standard C++ Library
> (Modena I think) for all the Unix platforms we support and MSVC++
> with its OEM'd Standard C++ Library, DinkumWare, for Windows
> NT/2000. Support the various 14882-1998, locale, and system support
> between the various compiler versions and platforms has been more of
> a nightmare than, IMHO, it should be.
nod. C++ isn't as mature as it could be. multiple-platform support
might be difficult. depending upon your application, perhaps you
would be better served by choosing a completely different language
such as smalltalk or common-lisp.
> I'm particularly having a hard time with KAI, or at least with its
> Standard C++ Libraries. Apparently, while it does support the ANSI-C
> notion of wchar_t, it has no support for the STDCPP wchar_t classes
> such as the all-important std::char_traits<wchar_t>, wstring,
> wiostream, etc. As if this weren't enough, on almost all platforms
> KAI supports it apparently has no support for mbstate_t. Finally, it
> seems that the only locale that any facet are implemented for is the
> "classic" locale, or "C" locale. Even some of those seem to be
> broken, basically, std::get_facet() doesn't work.
>
> I'd like some input regarding the following options:
>
> A) Use a single version of a single Vendors Standard C++ Library
> on every Platform including Windows NT. Unfortunately, what is
> offered by many companies (such as Rogue-Wave and ObjectSpace)
> is more like the Standard Template Library than the Standard C++
> Library.
i thought the standard template library (STL) was the standard C++
library.
> B) Find a standard C++ library that has *complete* 14882-1998
> support, or at least as complete as Plaguers Dinkumware Standard
> C++ Library that will work with all the platforms KAI supports,
> specifically HPUX, Redhat, SGI, AIX, and Solaris/Intel.
>
> C) Or, if there is no other choice, replace KAI with a compiler
> that has OEM'd runtimes that do have 14882-1998 compliance
> sufficient enough to create standardized international,
> multiplatform C++ programs.
>
> I am totally open to choices like GNU/OSF but using these for
> commercial projects is very new to me. The last I looked, the GNU
> C++ libraries didn't look like the 14882-1998 standard libraries,
> especially regarding NTMBS, NTWCS, locales, and facets. However, I
> would love to support these efforts by using them if there is a
> compliant implementation that will compiler with KAI and work with
> NT, SGI, Linux, Solaris/Intel, HPUX, and AIX.
--
J o h a n K u l l s t a m
[kullstam@ne.mediaone.net]
Don't Fear the Penguin!
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Scott Robert Ladd" <scott@coyotegulch.com>
Date: 1999/09/06 Raw View
Johan Kullstam <kullstam@ne.mediaone.net> wrote...
> i thought the standard template library (STL) was the standard C++
> library.
Unfortunately, no. Standard C++ made changes/additions to STL; STL, in turn,
has continued to grow in various forms.
I don't know if gcc has decent locale support... I just haven't had a chance
to look, but you might want to take a gander.
--
* Scott Robert Ladd
* Coyote Gulch Productions - http://www.coyotegulch.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: iszaw@homer.acetech.int (Jeff McWilliams)
Date: 1999/09/07 Raw View
In article <7r17ha$22qa$1@hardcore.ivn.net>, Scott Robert Ladd wrote:
>
>I don't know if gcc has decent locale support... I just haven't had a chance
>to look, but you might want to take a gander.
>
>--
> * Scott Robert Ladd
> * Coyote Gulch Productions - http://www.coyotegulch.com
>
The last time I checked (admittedly, 7 months ago) egcs did not support
std::wstring, and trying to use std::basic_string<wchar_t> also broke
during the compile.
Somebody is doing it though - as Debian is beginning to support many packages
with Japanese (Kanji ??) support. http://www.debian.or.jp/ is the
Debian JP Project website - so SOMEBODY is doing il8n.
Jeff
--
Jeff McWilliams - Advanced Development Engineer, ACE Technologies
jjmcwill@askacetech.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James.Kanze@dresdner-bank.com
Date: 1999/09/07 Raw View
In article <m2906k53qd.fsf@sophia.axel.nom>,
Johan Kullstam <kullstam@ne.mediaone.net> wrote:
> "Robert DiFalco" <rdifalco@tripwiresecurity.com> writes:
> > We are working on a project that has targets for Windoze NT, Linux,
> > AIX, HPUX, SGI, and Solaris that must support multiple native
> > locales, well... at least Japan (SJIS) and US/English.
> > We are currently using KAI with its OEM'd Standard C++ Library
> > (Modena I think) for all the Unix platforms we support and MSVC++
> > with its OEM'd Standard C++ Library, DinkumWare, for Windows
> > NT/2000. Support the various 14882-1998, locale, and system support
> > between the various compiler versions and platforms has been more of
> > a nightmare than, IMHO, it should be.
> nod. C++ isn't as mature as it could be. multiple-platform support
> might be difficult. depending upon your application, perhaps you
> would be better served by choosing a completely different language
> such as smalltalk or common-lisp.
His only problem seems to be finding a portable implementation of the
internationalization part of the library. Since Smalltalk or Common
Lisp don't have as extensive support for internationalization, I don't
see where they could help here.
> > I'm particularly having a hard time with KAI, or at least with its
> > Standard C++ Libraries. Apparently, while it does support the ANSI-C
> > notion of wchar_t, it has no support for the STDCPP wchar_t classes
> > such as the all-important std::char_traits<wchar_t>, wstring,
> > wiostream, etc. As if this weren't enough, on almost all platforms
> > KAI supports it apparently has no support for mbstate_t. Finally, it
> > seems that the only locale that any facet are implemented for is the
> > "classic" locale, or "C" locale. Even some of those seem to be
> > broken, basically, std::get_facet() doesn't work.
> > I'd like some input regarding the following options:
> > A) Use a single version of a single Vendors Standard C++ Library
> > on every Platform including Windows NT. Unfortunately, what is
> > offered by many companies (such as Rogue-Wave and ObjectSpace)
> > is more like the Standard Template Library than the Standard C++
> > Library.
> I thought the standard template library (STL) was the standard C++
> library.
The STL was adopted (and adapted) as *part* of the standard library.
STL doesn't concern itself in anyway with "presentation" issues like IO
or internationalization.
I'm pretty sure that the Dinkumware implementation would work with the
KAI compiler. On the other hand, I don't think Dinkumware sells to end
users.
> > B) Find a standard C++ library that has *complete* 14882-1998
> > support, or at least as complete as Plaguers Dinkumware Standard
> > C++ Library that will work with all the platforms KAI supports,
> > specifically HPUX, Redhat, SGI, AIX, and Solaris/Intel.
I'm not aware of a commercial one. As far as I know, g++ is somewhat
behind in this area as well.
> > C) Or, if there is no other choice, replace KAI with a compiler
> > that has OEM'd runtimes that do have 14882-1998 compliance
> > sufficient enough to create standardized international,
> > multiplatform C++ programs.
> > I am totally open to choices like GNU/OSF but using these for
> > commercial projects is very new to me. The last I looked, the GNU
> > C++ libraries didn't look like the 14882-1998 standard libraries,
> > especially regarding NTMBS, NTWCS, locales, and facets. However, I
> > would love to support these efforts by using them if there is a
> > compliant implementation that will compiler with KAI and work with
> > NT, SGI, Linux, Solaris/Intel, HPUX, and AIX.
Well, one way of supporting them would be to implement it yourself, then
donate the results to the cause:-). Seriously, getting some one to
implement it for you on contract might be your best bet. (I'd love such
a contract, but I'm not free at present:-(.)
Alternatively, you could simply use the C library. In terms of
functionality, C++ adds message library support (but with enough
implementation dependant points to make its portable use questionable)
and input/output code translation. It also associates a locale with
each stream, which is almost essential for the code translation. Neither
standard C nor C++ support positional parameters in a formatting string,
IMHO, one of the most essential issues -- most of the UNIX platforms you
mention do support it in printf, as an extension, but none of the NT
compilers does.
If I were on such a project, and the goal is not to create something
general or standard, I'd use the C library for most of the formatting
issues (date, money, collating sequences...) and I'd develop forwarding
streambuf's for the IO code translation. I've already got a class which
handles the formatting with positional parameters. But I've yet to find
a good, portable solution to the message catalog -- the typical Unix
system uses a string as an index, where as Windows, I think, uses ints.
--
James Kanze mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient e objet/
Beratung in objekt orientierter Datenverarbeitung
Ziegelh ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]