C ++:您会选择boost :: date_time还是icu :: date/time库? [英] C++: Will you choose boost::date_time or icu::date/time library?

查看:113
本文介绍了C ++:您会选择boost :: date_time还是icu :: date/time库?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

My application requires custom time and date setting capabilities. I checked both ICU and boost::date_time libraries. Both appears to meet my requirements from a completeness point of view. I would like to know if there is any preference between the two and on what basis? which one will score on performance?

推荐答案

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

Without more information about your specific use case and environment, there's no way to give a definitive answer as to whether either library out-performs the other. As Xeo suggested, profiling is the best way to address performance concerns.

如果您的用例包括通用"日期/时间操作(,则您尚不了解所需的全部日期/时间操作),有几种选择你必须做.作为 Boost.DateTime文档解释,您可以在以下三种功能之间进行选择:

If your use case includes "general" date/time manipulation (viz., you don't yet know the full spectrum of date/time operations that you need), there are a few choices you must make. As the Boost.DateTime documentation explains, you have a choice between these three capabilities:

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

为什么没有一个图书馆可以同时隐式处理这三个问题的一个原因是,确定给定时刻是否存在夏令时取决于司法管辖权,其政治问题以及许多其他因素.因此,涉及未来日期的计算可能会变得不准确.

One reason why no library can implicitly handle all three simultaneously is that the determination of whether daylight savings time exists at a given time instant depends on the jurisdiction, its political issues, and a host of other factors. As such, calculations that involve future dates may become inaccurate.

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

In deciding between these capabilities, you'll notice that geography and localization play an important role. If, for example, your date/time requirements need only support a single locale, there's not justifiable reason to introduce the large ICU library as a dependency. But, you probably shouldn't use Boost.DateTime, either: as a locale-agnostic library, it ignores the fact that the first day of the week varies by the locale. Additionally, Boost.DateTime's time zone support is broken; most modern software use the Olson database for time zone processing and conversions. Instead, you should probably consider Boost.Locale when using Boost to work with dates, times, and calendars.,

默认情况下,Boost.Locale 使用ICU用于所有本地化任务,但提供了使用非基于ICU的本地化后端的选项.因此,如果您(无论出于何种原因)没有在其他地方使用Boost,并且需要支持超出当前OS时区的时区以及从UTC偏移的时区(忽略夏时制),则仅使用ICU.如果您在其他地方使用Boost,则可以在Boost.Locale和ICU之间进行选择,但差异很小(最后,由于包含了ICU,因此这实际上是一个样式和一致性问题).当您不在其他地方使用Boost时,而仅在操作系统时区中处理日期(或使用先验与UTC已知的偏移量修改日期),最终的选择就会出现.在这种情况下,您可能应该使用Boost.Locale.DateTime,但不支持ICU.

By default, Boost.Locale uses ICU for all localization tasks, but provides the option to use non-ICU-based localization back-ends. So, if you're not using Boost elsewhere (for whatever reason) and need to support time zones beyond the current OS time zone and time zones shifted from the UTC (ignoring daylight savings time), then use only ICU. If you're using Boost elsewhere, you have a choice between Boost.Locale and ICU, but the differences are minimal (in the end, ICU is included, so it's really a stylistic and consistency question). The final choice arises when you're not using Boost elsewhere and you're only dealing with dates in the OS's time zone (or date modifications using an a priori known offset from the UTC). In that case, you should probably use Boost.Locale.DateTime, but without the ICU support.

  • 不要使用Boost.DateTime有两个原因:(1)它的时区支持被破坏; (2)忽略了星期几"计算取决于语言环境这一事实.改为使用Boost.Locale.DateTime.
  • 如果您在其他地方使用Boost,请继续使用它.它将自动包括基于ICU的本地化后端.您可以选择直接调用它们(直接包含ICU),但是没有太大区别.
  • 如果您没有在其他地方使用Boost,那么您的选择取决于用例是否与语言环境无关.如果与语言环境无关,则可以使用Boost.Locale.DateTime的非基于ICU的本地化后端(例如,std,posix),并避免ICU开销.另外,如果您的用例取决于语言环境,则可以使用ICU而不引入Boost的开销.
  • 关于性能:剖析是唯一了解方法.
  • Don't use Boost.DateTime for two reasons: (1) its time zone support is broken; and (2) it ignores the fact that "day of week" calculations depend on the locale. Use Boost.Locale.DateTime instead.
  • If you're using Boost elsewhere, then continue using it. It will automatically include the ICU-based localization back-ends. You may alternatively invoke them directly (by directly including ICU), but there's no major difference.
  • If you're not using Boost elsewhere, then your choice depends on whether the use case is locale-independent. If it's locale-independent, you can use Boost.Locale.DateTime's non-ICU-based localization backends (e.g., std, posix) and avoid the ICU overhead. Alternatively, if your use case depends on locale, then you can use ICU without introducing Boost's overhead.
  • On performance: profiling is the only way to know.

这篇关于C ++:您会选择boost :: date_time还是icu :: date/time库?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆