[Bug libstdc++/15992] locale ctor throws for all valid locales on SunOS

[sebor at roguewave dot com]

------- Additional Comments From sebor at roguewave dot com  2004-06-15 16:03 -------
Subject: Re:  locale ctor throws for all valid locales
 on SunOS

pcarlini at suse dot de wrote:

> ------- Additional Comments From pcarlini at suse dot de  2004-06-15 10:06 -------
> Hi Martin. On this platform we are using the 'generic' locale model, right? Not
> the 'gnu' locale model that needs glibc.

I suspected as much, I just didn't want to believe it was intentional.
The generic model is pretty much useless.

> 
> If you can confirm that the explanation it's easy: basically you cannot really
> use named localed in that model, just, 3.4 tells you much sooner!

Hmm. I thought 3.3.2 worked reasonably well but it sounds like
I thought wrong.

> 
...
>     // Currently, the generic model only supports the "C" locale.
>     // See http://gcc.gnu.org/ml/libstdc++/2003-02/msg00345.html

I remember this thread. I guess maybe I didn't realize back then
that on Solaris libstdc++ used the generic model. Or didn't have
time to respond to the RFC.

FWIW, it's possible to get C++ locale to work on Solaris (or any
other non-glibc platform). It may not be as fast or 100% thread-safe
as when you hook into the C library locale but it works well enough
and is portable enough that I think it outweighs the disadvantages.
With caching, the thread safety is only an issue at facet or locale
initialization time and only in programs that call setlocale()
directly, not when using the facets. Our primary locale model is
implemented this way and its performance is typically within 25%
of stdio.

Martin



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15992