[cfe-dev] [PATCH] Libc++ Windows fixes

[Howard Hinnant]

On Sep 23, 2011, at 12:40 PM, David Chisnall wrote:

> On 23 Sep 2011, at 17:30, Howard Hinnant wrote:
> 
>> But I agree that the *named* locale facility could use optimization, even when the name is "C".  But this is a very tricky area.  Please post non-trivial code for review prior to committing.
> 
> Absolutely.  The global "C" locale, and a named "C" locale are different in xlocale, since the locale_t contains some state used by the various multibyte functions.  
> 
> However...
> 
> Does the classic locale refer to the "C" locale, or the current global locale?  If it's the former, then it DOES need to be allocating memory (although in libc, not in libc++).  If it's the latter, then you have to be very careful with it because using the global locale from multiple threads is not safe (on FreeBSD or Darwin) if you call any of the mbs* functions.  You need to call duplocale() on the global locale if this is what you want, and have an instance of it for each thread.  

22.3.1.5 locale static members [locale.statics]:

static const locale& classic();

4  The "C" locale.

5  Returns: A locale that implements the classic "C" locale semantics, equivalent to the value locale("C"). 

6  Remarks: This locale, its facets, and their member functions, do not change with time.

Howard