C++ 0x中是否有任何本地化支持的更新？

Question

我使用C++语言环境方面的工作越多,我理解的就越多 - 它们就被打破了.

• std::time_get- 与std::time_put(因为它在C strftime/strptime中)不对称,并且不允许使用AM/PM标记轻松解析时间.
• 我发现最近,简单的数字格式可能产生在一定的语言环境(如非法UTF-8 ru_RU.UTF-8).
• std::ctype 假设可以在每个字符的基础上完成上/下更新(情况转换可能会改变字符数并且它取决于上下文),这是非常简单的.
• std::collate - 不支持校对强度(区分大小写或不区分大小写).
• 在时间格式化中无法指定与全局时区不同的时区.

以及更多...

• 有人知道C++ 0x中的标准方面是否有任何变化？
• 有没有办法让这种变化变得重要？

谢谢.

编辑:澄清链接无法访问:

std::numpunct将千位分隔符定义为char.因此,当U + 2002中的分隔符 - 不同类型的空间时,它不能作为单个字符在UTF-8中再现,而是作为多字节序列.

在C API中,struct lconv将千位分隔符定义为字符串,并且不会遇到此问题.因此,当您尝试使用UTF-8语言环境在ASCII之外的分隔符格式化数字时,会生成无效的UTF-8.

要重现此错误,请使用imbued ru_RU.UTF-8locale 将1234写入std:ostream

EDIT2:我必须承认POSIX C本地化API工作得更顺畅:

• 有strftime的反转 - strptime(strftime也一样std::time_put::put)
• 由于上面提到的问题,数字格式没有问题.

然而,它仍然是完美的.

编辑3:根据有关C++ 0x的最新说明,我可以看到std::time_get::get- 与...类似strptime和相反std::time_put::put.

Answer 1

std::numpunct是一个模板。所有专业化都尝试返回小数分隔符。显然，在任何宽字符的语言环境中，您应该使用std::numpunct<wchar_t>，因为<char专业化无法做到这一点。

也就是说，C++0x 已经基本完成了。然而，如果良好的改进持续下去，C++ 委员会很可能会启动 C++1x。如果通过您的国家 ISO 成员组织提供帮助，ISO C++ 委员会很可能会接受您的帮助。我看到帕维尔·米纳耶夫建议了一份缺陷报告。这在技术上是可行的，但您描述的问题属于一般设计限制。在这种情况下，最可靠的做法是为此设计一个 Boost 库，让它通过 Boost 审查，将其提交到标准中，并参加 ISO C++ 会议来处理其中出现的任何问题。