Robert DiFalco wrote:
>=20
> What is so hard about AIX support?

I didn't say it was hard, it's just not done yet.

>=20
> Martin Sebor <marts@att.net> wrote in message
> news:37D73C6A.D51E9736@att.net...
> Robert DiFalco wrote:
> >
> > Hmm...
> >
> > We are working on a project that has targets for Windoze NT, Linux, A=
IX,
> > HPUX, SGI, and Solaris that must support multiple native locales, wel=
l...  at
> > least Japan (SJIS) and US/English.
> >
> > We are currently using KAI with its OEM'd Standard C++ Library (Moden=
a 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 va=
rious
> > 14882-1998, locale, and system support between the various compiler v=
ersions
> > 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 St=
andard
> > 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 ha=
s no
> > support for mbstate_t. Finally, it seems that the only locale that an=
y 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 b=
y many
> > companies (such as Rogue-Wave and ObjectSpace) is more like the Stand=
ard
> > Template Library than the Standard C++ Library.
> >
> >     B) Find a standard C++ library that has *complete* 14882-1998 sup=
port,
> > or at least as complete as Plaguers Dinkumware Standard C++ Library t=
hat
> > will work with all the platforms KAI supports, specifically HPUX, Red=
hat,
> > SGI, AIX, and Solaris/Intel.
> >
> >     C) Or, if there is no other choice, replace KAI with a compiler t=
hat has
> > OEM'd runtimes that do have 14882-1998 compliance sufficient enough t=
o
> > create standardized international, multiplatform C++ programs.
> >
> > I am totally open to choices like GNU/OSF but using these for commerc=
ial
> > 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 NTM=
BS,
> > NTWCS, locales, and facets. However, I would love to support these ef=
forts
> > by using them if there is a compliant implementation that will compil=
er 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
> I doubt you'll find a single implementation that covers all the
> platforms. The soon-to-be-released implementation of our C++ Standard
> Library does have almost all that you're looking for, though (no AIX or
> SGI support at this time). Contact Rogue Wave's sales department for
> release schedule info.
>=20
> Martin Sebor
> Stdlib Tech Lead
> Rogue Wave Software
> ---
> [ 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             =
 ]
>=20
> [ 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             =
 ]
---
[ 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              ]

Robert DiFalco wrote:
>=20
> Hmm...
>=20
> 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.
>=20
> 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 vari=
ous
> 14882-1998, locale, and system support between the various compiler ver=
sions
> and platforms has been more of a nightmare than, IMHO, it should be.
>=20
> I'm particularly having a hard time with KAI, or at least with its Stan=
dard
> 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 o=
f
> those seem to be broken, basically, std::get_facet() doesn't work.
>=20
> I'd like some input regarding the following options:
>=20
>     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 Standar=
d
> Template Library than the Standard C++ Library.
>=20
>     B) Find a standard C++ library that has *complete* 14882-1998 suppo=
rt,
> or at least as complete as Plaguers Dinkumware Standard C++ Library tha=
t
> will work with all the platforms KAI supports, specifically HPUX, Redha=
t,
> SGI, AIX, and Solaris/Intel.
>=20
>     C) Or, if there is no other choice, replace KAI with a compiler tha=
t has
> OEM'd runtimes that do have 14882-1998 compliance sufficient enough to
> create standardized international, multiplatform C++ programs.
>=20
> I am totally open to choices like GNU/OSF but using these for commercia=
l
> projects is very new to me. The last I looked, the GNU C++ libraries di=
dn't
> look like the 14882-1998 standard libraries, especially regarding NTMBS=
,
> NTWCS, locales, and facets. However, I would love to support these effo=
rts
> 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.
>=20
> Thanks in advance for your help and please excuse the naivet=E9 of my p=
ost.
>=20

I doubt you'll find a single implementation that covers all the
platforms. The soon-to-be-released implementation of our C++ Standard
Library does have almost all that you're looking for, though (no AIX or
SGI support at this time). Contact Rogue Wave's sales department for
release schedule info.

Martin Sebor
Stdlib Tech Lead
Rogue Wave Software

> --
> Robert DiFalco
> Development Lead
> Tripwire Security Systems
>=20
> --
> Robert DiFalco
> Development Lead
> Tripwire Security Systems
> ---
> [ 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             =
 ]
---
[ 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              ]

What is so hard about AIX support?

Martin Sebor <marts@att.net> wrote in message
news:37D73C6A.D51E9736@att.net...
Robert DiFalco wrote:
>
> 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    of my post.
>

I doubt you'll find a single implementation that covers all the
platforms. The soon-to-be-released implementation of our C++ Standard
Library does have almost all that you're looking for, though (no AIX or
SGI support at this time). Contact Rogue Wave's sales department for
release schedule info.

Martin Sebor
Stdlib Tech Lead
Rogue Wave Software
---
[ 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              ]




[ 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              ]

Okay, dropping the locale issue for a moment, what about a library for Unix
that has proper support for wchar_t (wstring, wiostream, etc) and mbstate_t?

Benjamin Scherrey <scherrey@switchco.com> wrote in message
news:7r154k$nvo@news2.newsguy.com...
>
> Unfortunately locales is still pretty much bleeding edge as far as
standard
> library implementations are concerned. Typically, when I'm doing
> multi-platform development I try to make sure that I've got a g++
> implementation for all platforms even if that's not the environment that I
> intend to deploy on for each particular platform. This (having more than
one
> available compiler per environment) helps differentiate between os, tool,
or
> language issues during development. Unfortunately, I don't know of a
standard
> library implementation for g++ that has the features you specifically
need.
> I'd recommend talking to PJ Plauger or Greg Comeau about your issues to
see if
> they don't have implementations for their standard library/compliler
front-end
> implementations (respectively) that do what you need. I think I recall
that
> Comeau C++ had a front-end implementation for the KAI environment you
> mentioned. Obviously your biggest issue is ISO C++ compliance which just
isn't
> there for the major compiler vendors yet.
>
>         good luck,
>
>                 Ben Scherrey
>                 Proteus Technologies, Inc.
>
> In article <QeDA3.2009$Tf3.115763@news.uswest.net>, "Robert DiFalco"
> <rdifalco@tripwiresecurity.com> wrote:
> <snip>
> >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.
> <snip>
>
>
> [ 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              ]
>
---
[ 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              ]

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    of my post.

--
Robert DiFalco
Development Lead
Tripwire Security Systems

--
Robert DiFalco
Development Lead
Tripwire Security Systems
---
[ 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              ]

Unfortunately locales is still pretty much bleeding edge as far as standard
library implementations are concerned. Typically, when I'm doing
multi-platform development I try to make sure that I've got a g++
implementation for all platforms even if that's not the environment that I
intend to deploy on for each particular platform. This (having more than one
available compiler per environment) helps differentiate between os, tool, or
language issues during development. Unfortunately, I don't know of a standard
library implementation for g++ that has the features you specifically need.
I'd recommend talking to PJ Plauger or Greg Comeau about your issues to see if
they don't have implementations for their standard library/compliler front-end
implementations (respectively) that do what you need. I think I recall that
Comeau C++ had a front-end implementation for the KAI environment you
mentioned. Obviously your biggest issue is ISO C++ compliance which just isn't
there for the major compiler vendors yet.

        good luck,

                Ben Scherrey
                Proteus Technologies, Inc.

In article <QeDA3.2009$Tf3.115763@news.uswest.net>, "Robert DiFalco"
<rdifalco@tripwiresecurity.com> wrote:
<snip>
>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.
<snip>


[ 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              ]

"Robert DiFalco" <rdifalco@tripwiresecurity.com> writes:

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

If you're trying to implement the standard C++ library so that it's
portable to many different platforms, locales are a sticky issue. The
problem is that it's impossible to implement the C++ library's version
of locales in terms of the C library's version of locales in any
portable way; the models are fundamentally different.  If your goal is
for the C++ library on each platform to handle locales in the same way
that the platform's usual C library does (a reasonable goal; if
there's a "de" locale available from C, you'd hope that the "de"
locale in C++ does the same thing), then you've got a difficult
problem.  You have to read the same locale data files as the C
library, and interpret them in the same way, but you can't use the C
library's public interface.  I don't know of any really clean solution
to this problem, and it doesn't surprise me that some standard C++
library implementations lack full support for named locales.

In case you're curious, SGI's open source standard C++ library (see
http://www.sgi.com/Technology/STL/standard_library.html) attempts to
solve this problem by defining a narrow interface, which we call the
c_locale interface, to low-level locale functionality.  This interface
has to be reimplemented for each target platform.  There's also a
"stub" implementation, for platforms where c_locale has not yet been
ported.

Warning: our standard library's support for non-IRIX operating systems
is still experimental; it is not yet a solution to the problem of
portable C++ development.  I hope that will change soon.
---
[ 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              ]