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