This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

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

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: