The C++ locales is a cool feature for software internationalization and everybody certainly knows about or have heard of it. But when trying to use it on anything but a Windows or Linux system one may find out a crippled implementation. This is the case when GCC is ported to a different platform such as Solaris.
At first I thought it could be a simple matter of getting a more updated version of GCC. Then I've tried to document the potential solution on a previous post. But while digging into the matter I've sadly realized it's a more complicated issue.
As a matter of fact the issue lies in GNU libstdc++ which unfortunately does not provide a complete implementation of Locales. Its implementation is target just for systems already possessing a working implementation of the GNU C Library (glibc) which offers a key function usually found at newlocale.c source module that exposes the "special property" of being thread safe" at the C++ level". Solaris, as a standard UNIX system, uses libc which is thread safe just at the C level. Hence, GNU works around the issue by providing what is called a "general stub" only supporting "C" (= "POSIX") locale and otherwise throwing an exception. This has been made clear as per the following archived message: generic locale.
It seems that the main issue is an underlying libc limitation of not providing necessary API points for building up a multithreaded implementation of libstdc++ on top of it. As a consequence one entirely lacks a key C++ feature because of an unresolved multithreading issue. At this point it turns out easier to understand why there's a GNU C Library on the first place and why GNU libstdc++ relies on it instead of a particular system's libc.
But wondering about this multithreading issue between the C and C++ libraries when dealing with other locale dependent calls, one could realized that in most cases all that's necessary is to simply set the locale once on start-up code or while entering the main thread. From that point on, as long as a program remains pure C++ at the locale-dependent high-level I/O calls all should work pretty well.
I mean that in general a program isn't expected to be switching locales anymore after having properly intialized itself. I know I could be missing many reasons why the contrary should hold, but it seems they all would narrow down to some processing that should be carried out multiple times (in parallel) for different locales, such as processing some sort of localized I/O to several branch offices under a single process.
Therefore due to strictness, an all or nothing situation, one ends up with virtually nothing at all under Solaris and other less popular platforms for which nobody else carried about on providing a slightly more decent implementation of the C++ standard :-(
