708. Locales need to be per thread and updated for POSIX changes

Section: 30 [localization] Status: NAD Submitter: Peter Dimov Opened: 2007-07-28 Last modified: 2019-02-26 17:49:57 UTC

Priority: Not Prioritized

View all other issues in [localization].

View all issues with NAD status.


The POSIX "Extended API Set Part 4,"


introduces extensions to the C locale mechanism that allow multiple concurrent locales to be used in the same application by introducing a type locale_t that is very similar to std::locale, and a number of _l functions that make use of it.

The global locale (set by setlocale) is now specified to be per- process. If a thread does not call uselocale, the global locale is in effect for that thread. It can install a per-thread locale by using uselocale.

There is also a nice querylocale mechanism by which one can obtain the name (such as "de_DE") for a specific facet, even for combined locales, with no std::locale equivalent.

std::locale should be harmonized with the new POSIX locale_t mechanism and provide equivalents for uselocale and querylocale.

[ Kona (2007): Bill and Nick to provide wording. ]

[ San Francisco: Bill and Nick still intend to provide wording, but this is a part of the task to be addressed by the group that will look into issue 860. ]

[ 2009-07 Frankfurt: ]

It's our intention to stay in sync with WG14. If WG14 makes a decision that requires a change in WG21 the issue will be reopened.

Move to NAD Future.

[LEWG Kona 2017]

Recommend NAD: uselocale() is bad; pass locales around as objects

[Kona 2019]

Jonathan points out: The standard already allows per-thread locales, see [locale] p9.

Proposed resolution: