11

私のアプリケーションには、カスタムの時刻と日付の設定機能が必要です。ICUとboost::date_timeライブラリの両方をチェックしました。完全性の観点からは、どちらも私の要件を満たしているようです。両者の間に好みがあるかどうか、そしてどのような基準で知りたいですか？どちらがパフォーマンスで得点しますか？

4

1 に答える 1

12

特定のユースケースと環境に関する詳細情報がなければ、どちらかのライブラリが他方よりも優れているかどうかについて明確な答えを出す方法はありません。Xeoが示唆したように、プロファイリングはパフォーマンスの懸念に対処するための最良の方法です。

ユースケースに「一般的な」日付/時刻操作が含まれている場合（つまり、必要な日付/時刻操作の全範囲がまだわからない場合）、いくつかの選択を行う必要があります。Boost.DateTimeのドキュメントで説明されているように、次の3つの機能から選択できます。

  1. 実時間との正確な一致
  2. 瞬間間の正確な計算
  3. 将来の瞬間を処理する機能

3つすべてを同時に暗黙的に処理できるライブラリがない理由の1つは、特定の時点で夏時間が存在するかどうかの判断は、管轄区域、その政治的問題、およびその他の多くの要因に依存するためです。そのため、将来の日付を含む計算は不正確になる可能性があります。

これらの機能を決定する際に、地理とローカリゼーションが重要な役割を果たしていることに気付くでしょう。たとえば、日付/時刻の要件が単一のロケールのみをサポートする必要がある場合、依存関係として大規模なICUライブラリを導入する正当な理由はありません。ただし、おそらくBoost.DateTimeも使用しないでください。ロケールに依存しないライブラリとして、週の最初の日がロケールによって異なるという事実を無視します。さらに、Boost.DateTimeのタイムゾーンサポートは壊れています; 最新のソフトウェアのほとんどは、タイムゾーンの処理と変換にOlsonデータベースを使用しています。代わりに、Boostを使用して日付、時刻、およびカレンダーを操作する場合は、 Boost.Localeを検討する必要があります。

デフォルトでは、Boost.LocaleはすべてのローカリゼーションタスクにICUを使用しますが、非ICUベースのローカリゼーションバックエンドを使用するオプションを提供します。したがって、他の場所でBoostを使用しておらず（何らかの理由で）、現在のOSタイムゾーンを超えるタイムゾーンとUTCからシフトされたタイムゾーン（夏時間を無視）をサポートする必要がある場合は、ICUのみを使用してください。他の場所でBoostを使用している場合は、Boost.LocaleとICUのどちらかを選択できますが、違いはごくわずかです（最終的には、ICUが含まれているため、スタイルと一貫性の問題です）。最終的な選択は、他の場所でBoostを使用しておらず、OSのタイムゾーンの日付（またはアプリオリを使用した日付の変更）のみを処理している場合に発生します。UTCからの既知のオフセット）。その場合、おそらくBoost.Locale.DateTimeを使用する必要がありますが、ICUサポートはありません。

概要

  • Boost.DateTimeは、次の2つの理由で使用しないでください。（1）タイムゾーンのサポートが壊れている。（2）「曜日」の計算がロケールに依存するという事実を無視します。代わりにBoost.Locale.DateTimeを使用してください。
  • 他の場所でBoostを使用している場合は、引き続き使用してください。ICUベースのローカリゼーションバックエンドが自動的に含まれます。または、直接（ICUを直接含めることによって）それらを呼び出すこともできますが、大きな違いはありません。
  • 他の場所でBoostを使用していない場合、選択はユースケースがロケールに依存しないかどうかによって異なります。ロケールに依存しない場合は、 Boost.Locale.DateTimeの非ICUベースのローカリゼーションバックエンド（std、posixなど）を使用して、ICUのオーバーヘッドを回避できます。または、ユースケースがロケールに依存している場合は、Boostのオーバーヘッドを導入せずにICUを使用できます。
  • パフォーマンスについて：プロファイリングは知る唯一の方法です。
于 2012-03-03T05:07:33.770 に答える