What std::locale names are available on common windows compilers?

Question

The standard is pretty much silent on what constitutes a valid locale name; only that passing an invalid locale name results in std::runtime_error. What locale names are usable on common windows compilers such as MSVC, MinGW, and ICC?

Riplex

Answer 1

I believe the information you need is here :

locale  "lang[_country_region[.code_page]]"
            | ".code_page"
            | ""
            | NULL

This page provides links to :

• Language Strings
• Country/Region String
• Code Pages

---

Although my answers covers setlocale instead of std::locale, this MSDN page seems to imply that the format is indeed the same :

An object of class locale also stores a locale name as an object of class string. Using an invalid locale name to construct a locale facet or a locale object throws an object of class runtime_error. The stored locale name is "*" if the locale object cannot be certain that a C-style locale corresponds exactly to that represented by the object. Otherwise, you can establish a matching locale within the Standard C Library, for the locale object loc, by calling setlocale(LC_ALL, loc.name.c_str).

Also see this page and this thread which tend to show that std::locale internally uses setlocale.

Chandos

gcc does not support "Windows Style" locale names in std::locale, it supports only POSIX and C locales. – Engross

@Artyom: I don't see anything about gcc in this answer. – Riplex

@Billy ONeal I just relate to the question rather to the answer. So it would be just incorrect that std::locale in general supports this on Windows, but rather such locale names seems to be supported by MSVC only. – Engross

This answer is getting the checkmark because it's the most useful for what I'm working on at present time. – Riplex

Answer 2

Ok, there is a difference between C and C++ locales.

Let's start:

• MSVC C++ std::locale and C setlocale

  Accepts locale names as "Language[_Country][.Codepage]" for example "English_United States.1251" Otherwise would throws. Note: codepage can't be 65001/UTF-8 and should be consistent with ANSI codepage for this locale (or just omitted)

• MSVC C++ std::locale and C setlocale in Vista and 7 should accept locales [Language][-Script][-Country] like "en-US" using ISO-631 language codes and ISO 3166 regions and script names.

  I tested it with Visual Studio on Windows 7 - it does not work.

• MinGW C++ std::locale accepts "C" and "POSIX" it does not support other locales, actually gcc supports locales only over GNU C library - basically only under Linux.

  setlocale is native Windows API call so should support all I mentioned above.

  It may support wider range of locales when used with alternative C++ libraries like Apache stdcxx or STL Port.

• ICC - I hadn't tested it but it depends on the standard C++ library it uses. For example under Linux it used GCC's libstdc++ so it supports all the locales gcc supports. I don't know what standard C++ library it uses under Windows.

If you want to have "compiler and platform" independent locales support (and actually much better support) take a look on Boost.Locale

Artyom

Engross

+1 and interesting -- unfortunately the ICU library (upon which the proposed boost::locale depends) is prohibitively expensive (in terms of binary size) for most applications on which I work. :( – Riplex

@Billy ONeal you do not have to use ICU, Boost.Locale provides also standard library and Win32 API based backends that allow you to use same naming convention with different compilers (i.e. en_US.UTF-8) as on Posix systems. – Engross

Awarding the bounty to this answer because it most directly answers the question I originally asked. – Riplex

Answer 3

Here's one locale name that's usable pretty much anywhere: "". That is, the empty string. The is in contrast to the "C" locale that you are probably getting by default. The empty string as an argument to std::setlocale() means something like "Use the preferred locale set by the user or environment." If you use this, the downside is that your program won't have the same output everywhere; the upside is that your users might think it works just the way they want.

Elmore