MSVCRT printf 从不做千位分隔符分组，对吧？

Question

在 Windows 上，使用 Microsoft CRT 库 (MSVCRT)、printf/_snprintf/_snprintf_s/_snprintf_s_l 等确实会以某种方式考虑当前线程的 CRT 语言环境，但它们不会进行任何千位分隔符分组，对吗？

我尝试下面的代码：

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);

在VS2019中编译代码，我看到小数点字符随着“en-US”和“de-DE”而变化。 在德国，人们使用逗号作为小数点。

en-US: 7654321 | 1234567.890
de-DE: 7654321 | 1234567,890

但是你看，千组不会发生。

从localeconv()返回的lconv结构中，有关于分组的信息.grouping=0x03 。 看起来这个.grouping信息实际上并没有被 MSVCRT 内部使用，相反，我们的应用程序代码必须消化这些信息并自己进行分组，对吧？

我想问的是：微软有没有提供任何文档列出哪些“语言环境属性”实际实现了，哪些没有？

如果没有提供这样明确的信息，我认为我们应该避免依赖 CRT 层提供的那些“文化”属性，相反，使用Winnls.h （WinAPI 层）中的另一组语言环境函数可能是更好的 promise。 例如， SetThreadLocale()设置/更改 WinAPI 层当前线程语言环境，然后GetNumberFormat() ，我们将看到应用了千位分隔符。

==== 更新 ====

好吧，现在我明白了。 MSDN 告诉它，但措辞很棘手。

千位分隔符仅反映在localeconv()返回的lconv结构中； 它不会影响printf行为。 因此， .grouping不影响 `printf' 也就不足为奇了。

Answer 1

问：MSVCRT printf 从不做千位分隔符分组，对吗？

正确的。 Single UNIX 规范有一个扩展，它在提供'标志时添加千位分隔符。 但这不是由 MSVCRT 实现的。

问：Microsoft 是否曾提供任何文档列出实际实现了哪些“语言环境属性”，哪些未实现？

较新版本的 MSVCRT 严格遵循 C 标准。 C11 标准说明了setlocale ：

LC_COLLATE 影响 strcoll 和 strxfrm 函数的行为。 LC_CTYPE 影响字符处理函数以及多字节和宽字符函数的行为。 LC_MONETARY 影响 localeconv function 返回的货币格式信息。 LC_NUMERIC 影响格式化输入/输出函数和字符串转换函数的小数点字符，以及 localeconv function 返回的非货币格式化信息。 LC_TIME 影响 strftime 和 wcsftime 函数的行为。

这在Microsoft 的 setlocale function 文档中也有详细说明。

请注意，大多数 C 库函数从未使用 localeconv 返回的大多数信息（尤其是与货币值相关的任何信息）。 这是设计使然。 我认为实际上只使用了decimal_point 。