ICU与C++中的Boost Locale

17 c++ unicode boost icu c++11

我正在考虑使用ICU或Boost Locale.

各自的优点和缺点是什么?

我知道两者都使用ICU,但是ICU被Boost Locale隐藏.根据Boost Locale的基本原理页面:"......整个ICU API隐藏在不透明指针之后,用户无法访问它."

在比较这些库时,请考虑C++ 11中的新Unicode功能.

Art*_*yom 16

ICU是非常好的库,但它有缺点:

  1. API在现代C++设计方面非常糟糕,并且与标准C++库不兼容
  2. 它以UTF-16为导向
  3. 它的消息转换工具远非完美,这就是Boost.Locale使用Gettext模型的原因

请参阅:http://www.boost.org/doc/libs/1_49_0/libs/locale/doc/html/rationale.html#why_icu

Boost.Locale以C++方式进行本地化,并允许使用除ICU之外的其他后端(当然ICU更好),因此在许多情况下Boost.Locale为您提供更好的本地化替代方案,因为它更简单,专为现代C++而设计更容易使用.

当然,如果您需要Boost.Locale不支持的非常复杂的算法,或者您的应用程序所做的全部是Unicode处理,那么ICU可能会更好,除了Boost.Locale更适合本地化C++应用程序.


Mih*_*ita 2

ICU是由国际化专家设计的,而boost是由C++程序员设计的。

虽然 C++ 强大且优雅,但 boost 在国际化方面存在很多错误。现在,boost 是一个库的大集合,其中一些库比其他库做得更好。但 ICU 自始至终都很稳固,除了 Microsoft 之外,几乎所有公司都将其用作基础。

因此,如果你想要扎实的国际化,就选择 ICU。如果你想要最先进的 C++(但 i18n 有点不稳定),那就去 boost。

  • -1。OP 希望对 ICU 和 *Boost.locale* 进行比较。诸如“boost 在国际化方面出现了很多错误 [...] boost 是一个库的大集合,有些库比其他库做得更好”这样的说法完全是题外话。Boost.locale 是一个应该包装 ICU 和 GNUGettext 的库那么问题是效果如何?直接用ICU好还是不用? (18认同)
  • @MihaiNita:听起来你正在传播一些古老的 FUD。当然,库可能包含错误,但这些错误比用户代码中的错误更有可能被社区发现和修复。使用设计良好的现代库作为 Boost.Locale 的好处是,用户代码中的错误可能比直接使用 ICU 更少。 (6认同)
  • 这些都是对 Boost.Locale 的严厉批评。例如,*大多数 boost 子库根本不考虑 i18n。它们被设计所破坏。*对于如此强烈的陈述,一个**例子**是合适的。Boost.Locale 的哪些设计缺陷使其“被设计破坏”?就目前情况而言,我必须执行我的第一次国际化迁移,我来这里寻求有关使用 Boost.Locale 是否是个好主意,或者我是否应该直接使用 ICU 的建议。不幸的是,你的批评对我来说**有用**,因为你没有提供证据。或许你可以填写一下? (5认同)
  • 答案有点含蓄:直接进ICU。由于 Boost.locale 是一个包装器,因此它只能与 ICU 一样好或更差。它可能看起来比 ICU 更好,但也可能引入额外的错误(我知道包装 ICU 的 Mac OS X API 引入了 ICU 中没有的错误)。此外,Boost.locale 始终采用 UTF-8。由于 ICU 在 UTF-16 上工作,这意味着所有调用都必须进行 UTF-8 到 UTF-16 的转换以及返回、映射字符串偏移量等。性能受到影响,并且容易出错。 (4认同)