11

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

  • std::time_get-- 与std::time_put（如在 C strftime/strptime 中一样）不对称，并且不允许使用 AM/PM 标记轻松解析时间。
  • 我最近发现，在某些语言环境（如ru_RU.UTF-8）下，简单的数字格式可能会产生非法的 UTF-8。
  • std::ctype假设上/下可以在每个字符的基础上完成（大小写转换可能会改变字符数并且它取决于上下文）是非常简单的。
  • std::collate-- 不支持排序规则（区分大小写或不区分大小写）。
  • 无法在时间格式中指定与全球时区不同的时区。

以及更多...

  • 有人知道 C++0x 的标准方面是否会发生任何变化？
  • 有什么方法可以带来这种变化的重要性？

谢谢。

编辑：如果链接无法访问，请进行说明：

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

在 C APIstruct 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.

4

2 回答 2

4

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

有人知道 C++0x 的标准方面是否会发生任何变化？

游戏太晚了，所以可能不会。

有什么方法可以带来这种变化的重要性？

我对此非常悲观。

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

而 boost 中的一些线程（这似乎会推动未来的发展方向）对它的工作原理知之甚少，这完全是可怕的。

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

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

于 2009-11-10T10:51:37.963 回答
1

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

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

于 2009-10-08T08:14:02.867 回答