On Windows, using Microsoft CRT library(MSVCRT), printf/_snprintf/_snprintf_s/_snprintf_s_l etc do consider current thread's CRT locale somehow, but they do NOT do any thousand separator grouping right?
I try the code below:
int i1 = 7654321;
double d1 = 1234567.89;
char *locret = nullptr;
setvbuf(stdout, NULL, _IONBF, 0);
locret = setlocale(LC_ALL, "en-US");
assert(locret);
printf("en-US: %d | %.3f\n", i1, d1);
locret = setlocale(LC_ALL, "de-DE");
assert(locret);
printf("de-DE: %d | %.3f\n", i1, d1);
Compile the code in VS2019, I see that decimal point character varies with "en-US" and "de-DE". In Germany, people use comma as decimal point.
en-US: 7654321 | 1234567.890
de-DE: 7654321 | 1234567,890
But you see, thousand-grouping does NOT happen.
From the lconv struct returned by localeconv(), there is information about grouping, .grouping=0x03. Looks like this .grouping info is never actually used by MSVCRT internally, instead, our application code has to digest this info and do grouping ourselves, right?
What I'd like to ask is: Does Microsoft ever provide any document listing which "locale properties" are actually implemented, and which are not?
If no such clear info is provided, I think we should avoid relying on those "culture" property provided by CRT-layer, instead, using another herd of locale functions from Winnls.h (WinAPI-layer) may be a better promise. For example, SetThreadLocale() sets/changes WinAPI-layer current thread-locale, then GetNumberFormat(), and we will see thousand separator applied.
==== Update ====
Well, now I get it. MSDN tolds it, but the wording is tricky.
The thousand separator character is only reflected in the lconv struct returned by localeconv(); it does not affect printf behavior. So, .grouping not affecting `printf' is unsurprising as well.

