You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Without all this, you will get situations where format("%g",123.45)
might return "123,45" if it happens to be running on a machine with
locale "fr_FR", for example. If that is written to an output file that
is later read on a computer using a locale with '.' as the decimal mark,
it could mis-parse as "123.0", leading to hilarious and tragic results.
It seems like the safe thing is to force the string-returning varieties
of tinyformat to use classic locale ('.' decimal), with an optional
means for the odd users to purposely specify a different (or native)
locale. It also seems that the best policy for the stream-appending
varieties of format() is to use the local already associated with those
streams (C++ lets each stream have its own locale).
1. format() to an existing stream (including cout) is now documented to
honor the stream's existing locale (as it always did).
2. format() that returns a string now will always format the string using
the classic "C" locale, in particular meaning that floating point
numbers will use '.' as the decimal mark, regardless of the "native"
locale set by the OS or process that may have an unexpected choice of
decimal point.
3. Add a new variety of format() that returns a string, but which takes
an explicit locale, for cases where you don't want the "C" locale
(for example, when generating strings that will appear in a UI that
you want localized properly). You can make this variety use the
current locale by passing std::locale() as the first argument (the
default constructor of std::locale just grabs the global process
locale).
0 commit comments