Replacement for snprintf
H. S. Teoh
hsteoh at quickfur.ath.cx
Fri Nov 1 17:02:53 UTC 2019
On Fri, Nov 01, 2019 at 01:01:21PM +0000, Jacob Carlborg via Digitalmars-d wrote:
> On Thursday, 31 October 2019 at 15:58:08 UTC, H. S. Teoh wrote:
>
> > Which leads me to think that these two should be separate format
> > specifiers.
>
> I would put the localization in a completely different function.
That would be a better solution. It would be different from snprintf,
though, and we'd have to document it well so that people can find it.
> > Unfortunately, I can see how this would force format() to be impure,
> > because to support checking the current locale implies accessing
> > global state, which is impure.
>
> You could pass in the locale to the function, then it can be pure.
> Even more reason to have it as a separate function. I would say that
> should be best practice because you might want to run a program in a
> different locale than the global configured one.
+1.
> I'm not sure if it's enough to look at the locale. On my computer (a
> Mac) I have configured it to have the language in English but the
> date, time, number and currency format to Swedish.
[...]
I think it has to do with the LC_* environment variables, at least on a
*nix system. You can set LC_ALL to get the same settings across all
categories, or you can separately set one or more of the LC_* to get
different settings in each category. (Caveat: I've never actually done
this myself before, so I could be misunderstanding how it works.)
T
--
Famous last words: I wonder what will happen if I do *this*...
More information about the Digitalmars-d
mailing list