As we all know, global data, like the locale settings affecting the numeric decimal point printf() and strtod() are using, is evil. Fortunately, MSVC++ 9 allows to use per-thread locales by a _configthreadlocale(_ENABLE_PER_THREAD_LOCALE) call. Unfortunately, it seems that the localeconv() function does not notice this and still returns the global locale settings, e.g. localeconv()->decimal_point seems to always return the global locale setting before the _configthreadlocale() call. Is this a bug in the MSVC library or is this expected?
TIA
Paavo
Despite the suggestion that this is expected behaviour from rubenvb, this is actually a bug that I ran into a while ago. I suspect rubenvb misread this part of the question:
Unfortunately, it seems that the localeconv() function does not notice this and still returns the global locale settings, e.g. localeconv()->decimal_point seems to always return the global locale setting before the _configthreadlocale() call.
The question wasn't intending on having localeconv() return on a per-thread basis before calling _configthreadlocale() as that would break the time continuum. The question was suggesting that the results of calling localeconv() after calling _configthreadlocale() are the same as calling it beforehand, which is unexpected. This essentially means Microsofts implementation of the C++ STL streams are fundamentally broken when using _configthreadlocale().
The call to the _configthreadlocale sets the property, before the call, nothing special happens. So yes, this is expected behavior. You first must call this function, and then you can take advantage of thread-local locales.
