11

我的应用程序需要自定义时间和日期设置功能。我检查了 ICU 和 boost::date_time 库。从完整性的角度来看，两者似乎都符合我的要求。我想知道两者之间是否有任何偏好以及基于什么？哪一个会在性能上得分？

4

1 回答 1

12

如果没有关于您的特定用例和环境的更多信息，就无法给出任何一个库是否优于另一个库的明确答案。正如 Xeo 所建议的，分析是解决性能问题的最佳方式。

如果您的用例包括“一般”日期/时间操作（即，您还不知道所需的日期/时间操作的全部范围），那么您必须做出一些选择。正如Boost.DateTime 文档所解释的，您可以在以下三种功能之间进行选择：

  1. 与挂钟时间完全一致
  2. 时刻之间的准确计算
  3. 处理未来时间瞬间的能力

没有图书馆可以隐式同时处理这三个方面的一个原因是，夏时制是否存在于给定时间瞬间的确定取决于管辖权、其政治问题和许多其他因素。因此，涉及未来日期的计算可能会变得不准确。

在选择这些功能时，您会注意到地理和本地化起着重要作用。例如，如果您的日期/时间要求只需要支持单个语言环境，则没有正当理由将大型 ICU 库作为依赖项引入。但是，您可能也不应该使用 Boost.DateTime：作为与语言环境无关的库，它忽略了一周的第一天因语言环境而异的事实。此外，Boost.DateTime 的时区支持被破坏；大多数现代软件都使用Olson 数据库进行时区处理和转换。相反，在使用 Boost 处理日期、时间和日历时，您可能应该考虑Boost.Locale 。

默认情况下，Boost.Locale将 ICU 用于所有本地化任务，但提供了使用非基于 ICU 的本地化后端的选项。因此，如果您没有在其他地方使用 Boost（无论出于何种原因）并且需要支持当前操作系统时区之外的时区和从 UTC 偏移的时区（忽略夏令时），那么请仅使用 ICU。如果您在其他地方使用 Boost，您可以在 Boost.Locale 和 ICU 之间进行选择，但差异很小（最后，ICU 包括在内，所以这确实是一个风格和一致性问题）。当您不在其他地方使用 Boost 并且您只处理操作系统时区中的日期（或使用先验的日期修改）时，会出现最终选择与 UTC 的已知偏移量）。在这种情况下，您可能应该使用 Boost.Locale.DateTime，但没有 ICU 支持。

概括

  • 不要使用 Boost.DateTime 有两个原因：（1）它的时区支持被破坏了；(2) 它忽略了“星期几”计算取决于地区的事实。请改用 Boost.Locale.DateTime。
  • 如果您在其他地方使用 Boost，请继续使用它。它将自动包含基于 ICU 的本地化后端。您也可以直接调用它们（通过直接包括 ICU），但没有大的区别。
  • 如果您没有在其他地方使用 Boost，那么您的选择取决于用例是否与语言环境无关。如果它与语言环境无关，您可以使用 Boost.Locale.DateTime 的非基于 ICU 的本地化后端（例如，std、posix）并避免 ICU 开销。或者，如果您的用例依赖于语言环境，那么您可以使用 ICU 而不会引入 Boost 的开销。
  • 关于性能：分析是了解的唯一方法。
于 2012-03-03T05:07:33.770 回答