locale for floating point numbers

[steffen-kiess]

(Continuation of https://github.com/jacobsa/jsoncpp/pull/2, rebased against current master)

Hmm. I'm not sure this was a good change. snprintf is more efficient. You can set the locale for snprintf too:

http://stackoverflow.com/questions/3457968/snprintf-simple-way-to-force-as-radix

Was this a problem only on Windows?

It think the problem will be there both under Linux and Windows (I was using Linux).

The problem is that setlocale() will replace the locale globally (which means it is a bad idea to call it from a library) and uselocale() is POSIX-specific.

I think you had 2 problems. First, you might have had issues with your tool-chain. If you set LC_ALL in your makefile and export it, then it becomes the default. From your code, I am not sure how you were injecting it. I would need to see your makefile.

I wasn't setting the locale during compilation but when executing the binary.

Second, and more important, you need to run set locale(LC_NUMERIC, val) after you set the global locale.

Here is my makefile and example, which works as expected:

https://gist.github.com/cdunn2001/61bc4a05ce906492defd

So I would like to revert your change. Is that ok?

Resetting the LC_NUMERIC locale to "C" will work, but that means that either the library has to do it (which IMHO is a bad idea when doing it globally) or the program has to do it. I think that requiring the program to change the locale is not a good idea either; many developers will never notice the problem when they are using a US locale for development.

Another possibility to fix the problem would be to replace the ',' by a '.' after calling snprintf(), AFAIK there are no locales which use something other than '.' or ','. Doing this feels weird, but probably will work and has almost the same performance as just calling snprintf().

[cdunn2001]

How about setting the locale only in the Writer, and resetting in its destructor?

• New pull request: LC_NUMERIC locale #5

[cdunn2001]

The change seems to have broken someone on WinCE. I will try to learn whether it is only a matter of an old compiler. Feel free to offer suggestions here: #9

[cdunn2001]

Well, the compiler is bit old, but not unreasonably so. Details in #9 (comment)

So we have a quandary:

1. Shall we support locales properly?
2. Or shall we maintain compatibility with 2008 WinCE?

I lean toward reverting the change, and then simply substituting , for . in the result.

[cdunn2001]

Reverted your change, but the problem should be fixed for you now on the master branch. Thanks for the bug-fix and for teaching me some stringstream details.