I have an interesting problem with C++ locales. We have a DLL which takes text string parameters and does some hardware interfacing. The details of that aren't too important; the main point is that it's a DLL and not a statically-linked library.
We found that there was a problem for European users, where they use commas as decimal symbols. The DLL was still using the default C locale with decimal points, so it didn't interpret them correctly. Adding the call std::locale::global(std::locale("")); in the DLL picked up the current locale settings and made this work correctly.
I've now found that this causes separate problems with programs using the DLL though. A calling program (a separate EXE which dynamically loads the DLL) now prints numbers with thousand separators, picked up from the current locale. I can prove that this is the reason by changing the locale settings and by testing with old and new DLLs. But the calling program is unchanged - only the DLL loads the locale. The calling program never had a locale set so was still using the default C locale.
Is this expected behaviour? I expected each separately-compiled executable to have its own std::locale::global settings - I did not expect DLLs to reference (and change) a program-wide setting in the calling program. Am I correct here, or is this a bug in the C++ runtime?
I've looked at the appropriate reference pages here and here but it doesn't seem clear to me that it should work this way.
(We're using the MSVC 2013 runtime, by the way. Yes I know it's old - we just haven't had a strong reason to change yet.)