我对 C++ 语言环境方面的研究越多，我就越了解——它们已经被破坏了。
-
std::time_get-- 不对称std::time_put（如 C strftime/strptime 中所示）并且不允许轻松解析带有 AM/PM 标记的时间。
- I 发现 http://art-blog.no-ip.info/cppcms/blog/post/49最近，简单的数字格式可能会在某些区域设置下产生非法的 UTF-8（例如
ru_RU.UTF-8).
-
std::ctype假设可以在每个字符的基础上完成上/下操作，这是非常简单的（大小写转换可能会改变字符数，并且它取决于上下文）。
-
std::collate-- 不支持排序规则强度（区分大小写或不敏感）。
- 无法在时间格式中指定与全局时区不同的时区。
以及更多...
- 有谁知道 C++0x 中的标准方面是否会发生任何变化？
- 有没有什么方法可以让这些改变变得重要？
Thanks.
EDIT:链接无法访问时的说明：
std::numpunct将千位分隔符定义为 char。因此，当 U+2002 中的分隔符 -- 不同类型的空间时，它不能作为 UTF-8 中的单个字符再现，而是作为多字节序列再现。
在 C API 中struct lconv将千位分隔符定义为字符串并且不会遇到此问题。因此，当您尝试使用 UTF-8 语言环境使用 ASCII 之外的分隔符格式化数字时，会生成无效的 UTF-8。
要重现此错误，请使用 imbued 将 1234 写入 std:ostreamru_RU.UTF-8 locale
EDIT2:我必须承认 POSIX C 本地化 API 工作起来更加流畅：
- strftime 的倒数 -- strptime （strftime 与
std::time_put::put)
- 由于我上面提到的这一点，数字格式没有问题。
然而它还远未达到完美。
EDIT3:根据有关 C++0x 的最新注释我可以看到std::time_get::get- 如同strptime和相反的std::time_put::put.
我同意你的观点，C++ 缺乏适当的 i18n 支持。
有谁知道 C++0x 中的标准方面是否会发生任何变化？
比赛已经太晚了，所以可能不会。
有没有什么方法可以让这些改变变得重要？
我对此非常悲观。
当被直接询问时，斯特劳斯特鲁普声称他认为目前的状况没有任何问题。如果您阅读了标准，另一位 C++ 大佬（本书作者和所有人）甚至没有意识到 wchar_t 可以是一个字节。
而且 boost 中的一些线程（这似乎推动了未来的方向）对它的工作原理知之甚少，这真是太可怕了。
C++0x 在游戏后期和经过一番努力之后才勉强添加了一些 Unicode 字符数据类型。我不会屏息以待更多。
我想看到更好的东西的唯一机会是如果 i18n 和 C++ 世界中真正优秀/受人尊敬的人直接参与下一版本的标准。不知道那可能是谁:-(
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
