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

Question

我使用C ++语言环境方面的工作越多，我就越了解 - 它们已经坏了。

• std::time_get - 与std::time_put不对称（在C strftime / strptime中），并且不允许使用AM / PM标记轻松解析时间。
• 我discovered最近简单的数字格式可能会在某些区域设置下产生非法的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。

要重现此错误，请将1234写入带有ru_RU.UTF-8语言环境的std：ostream

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

• strftime的反转 - strptime（strftime与std::time_put::put相同）
• 由于上面提到的问题，数字格式没有问题。

然而，它仍然是完美的。

EDIT3：根据有关C ++ 0x的最新说明，我可以看到std::time_get::get - 与strptime类似，与std::time_put::put相反。< / p>

Answer 1

我同意你的看法，C ++缺乏适当的i18n支持。

  

有人知道在C ++ 0x的标准方面是否预期会有任何变化吗？

游戏已经太晚了，所以可能没有。

  

有没有办法让这些变化变得重要？

我对此非常悲观。

当被直接询问时，Stroustrup声称他没有看到当前状态的任何问题。另外一个大C ++人（书籍作者和所有人）甚至没有意识到wchar_t可以是一个字节，如果你阅读标准。

并且一些提升中的线索（似乎在将来推动了这个方向）显示出对如何工作的理解很少，这是完全可怕的。

C ++ 0x几乎没有添加一些Unicode字符数据类型，在游戏后期和经过很多努力之后。我不会太快屏住呼吸。

我想唯一一个看到更好的东西的机会是，如果有人在i18n和C ++世界中真正优秀/受到尊重，那么直接参与下一版本的标准。不知道那可能是谁： - （

Answer 2

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

也就是说，C ++ 0x已经完成了。但是，如果继续保持良好的改进，C ++委员会可能会启动C ++ 1x。如果通过您的国家ISO成员组织提供，ISO C ++委员会很可能会接受您的帮助。我看到Pavel Minaev提出了一份缺陷报告。这在技术上是可行的，但是您描述的问题在于一般的设计限制。在这种情况下，最可靠的行动方案是为此设计一个Boost库，让它通过Boost评审，提交它以包含在标准中，并参加ISO C ++会议来处理那里出现的任何问题。