支持和反对在跨平台库中独占支持std :: wstring的参数

Question

我目前正在开发一个跨平台的C ++库，我打算用Unicode识别它。我目前通过typedef和宏对std :: string或std :: wstring进行编译时支持。这种方法的缺点是它会强制您使用L("string")之类的宏，并根据字符类型大量使用模板。

支持std :: wstring只支持和反对的论据是什么？

使用std :: wstring会不会影响GNU / Linux用户群，首选UTF-8编码？

Answer 1

很多人都希望使用UTF-8（std :: string）而不是UCS-2（std :: wstring）的unicode。 UTF-8是许多Linux发行版和数据库的标准编码 - 所以不支持它将是一个巨大的劣势。在Linux上，每次使用字符串作为参数调用库中的函数都需要用户将（本机）UTF-8字符串转换为std :: wstring。

在gcc / linux上，std :: wstring的每个字符都有4个字节，而在Windows上则有2个字节。在读取或写入文件（以及从/向不同平台复制文件）时，这会导致奇怪的效果。我宁愿为一个跨平台项目推荐UTF-8 / std :: string。

Answer 2

  

支持std :: wstring只支持和反对的论据是什么？

支持使用宽字符的论据是它可以做所有狭窄的字符可以做更多。

我所知道的反对它的论点是：

• 广泛的角色需要更多的空间（这几乎不相关，中国人原则上不会比美国人对记忆有更多麻烦）
• 使用宽字符给一些西方人带来了麻烦，这些西方人用于使他们的所有角色都适合7位（并且不愿意学会注意不要将字符类型的混合使用用于实际角色与其他用途）

至于灵活性：我维护了一个可以处理窄字符和宽字符的库（几个kLoC）。大多数是通过字符类型作为模板参数，我不记得任何宏（除UNICODE之外）。然而，并非所有这些都是灵活的，其中有一些代码最终需要char或wchar_t字符串。 （使用宽字符制作内部键字串时没有意义。）
用户可以决定他们是否只需要狭隘的字符支持（在这种情况下"string"很好）或只需要广泛的字符支持（要求他们使用L"string"），或者他们是否也想支持两者（需要T("string")之类的东西。

Answer 3

有关：

• Joel Spolsky写道The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets。如果你滚动到底部，你会发现他的工作人员只使用宽字符串。如果它对他们来说足够好，那对你来说已经足够了。 ; - ）

反对：

• 您可能必须与不支持i18n的代码进行交互。但是就像任何一个好的图书馆作家一样，你只是把这个混乱隐藏在一个易于使用的界面背后，对吧？正确？

Answer 4

我会说使用std::string或std::wstring无关紧要。

无论如何都没有提供适当的Unicode支持。

如果您需要国际化，那么您需要适当的Unicode支持，并且应该开始调查ICU等库。

之后，这取决于使用哪种编码，这取决于您所使用的平台：将依赖于操作系统的设施包装在抽象层后面，并在适用时转换为实现层。

不要担心您使用的Unicode库（或构建？hum）内部使用的编码，这是性能问题，不应影响库本身的使用。

Answer 5

缺点：

因为wstring是真正的UCS-2而不是UTF-16。有一天，我会踢你的小腿。它会很难。