2

boost::units科学プロジェクトで物理的な一貫性を確保するためにライブラリを使用しています。ブーストのドキュメントからいくつかの例を読んで試しました。寸法、単位、数量を作成できます。私はいくつかの計算をしました、それは非常にうまくいきます。それはまさに私が期待したものです...

私のプロジェクトでは、6 つの次元に基づくいくつかの異なる単位 (温度、濃度、密度など) を持つ時系列を扱います。安全で簡単な単位変換を可能にするために、時系列のディメンションと単位を表すメンバーを各チャネル クラスに追加したいと思います。また、データ処理 (インポート、変換など) はユーザー主導であるため、動的です。

私の問題は次のとおりです。boost::units構造のため、均質なシステム内の数量は異なりますが、次元が異なると、タイプが異なります。したがって、次のようなメンバーを直接宣言することはできません。

boost::units::quantity channelUnits;

コンパイラは、テンプレートのシェブロンを使用して寸法を指定する必要があると主張します。しかし、そうすると、異なるタイプの数量 (たとえば、異なる次元の数量) を格納できなくなります。

次に、boost::units::quantity宣言を探して、ポリモーフィックな方法で使用できる基底クラスがあるかどうかを調べました。しかし、私はそれを見つけていません。代わりに、テンプレート メタ プログラミングboost::unitsを多用していることを発見しました。これは問題ではありませんが、すべてが実行時ではなくコンパイル時に解決されるため、動的なニーズに正確には適合しません。

さらに読んだ後、オブジェクトにさまざまな量をラップしようとしましたboost::variant（初めて会えてうれしいです）。

typedef boost::variant<
   boost::units::quantity<dim1>,
   ...
> channelUnitsType;
channelUnitsType channelUnits;

いくつかのテストを実行しましたが、うまくいくようです。しかし、私はboost::variantと訪問者パターンに自信がありません。

私の質問は次のとおりです。

  • 実行時の型解決を行うための別の - おそらく最良の - 方法はありますか?
  • dynamic_castそれらの1つですか？単位変換は頻繁には行われず、関係するデータはごくわずかです。
  • 適切なソリューションである場合boost::variant、その欠点は何ですか?
4

2 に答える 2

3

私の問題をさらに深く掘り下げると、解決策のトラックを提供する 2 つの記事を読みました。

  • Kostadin Damevski、科学コンポーネント ソフトウェアのインターフェイスでの測定単位の表現。
  • Lingxiao Jiang、C プログラムの次元単位の正しさを検証するための実用的な型システム。

1 つ目は、インターフェイスの実装に関する優れたアイデアを提供します。2 つ目は、対処しなければならないことの完全な概要を示しています。

boost::unitsこれは、実行時のオーバーヘッドなしで、コンパイル時の次元の一貫性を確保するための完全かつ効率的な方法であることを覚えておいてください。とにかく、次元の変更を含む実行時の次元の一貫性のためにboost::unitsは、提供しない動的構造が必要です。だからここに私はいます：私のニーズにぴったり合うユニットクラスを設計しています。より多くの仕事を達成し、最終的にはより多くの満足を得る...

元の質問について：

  • boost::variantこのジョブではうまく機能します（ダイナミックboost::unitsが欠落していることを提供します）。さらに、箱から出してシリアル化することもできます。したがって、それは効果的なアプローチです。しかし、それは、単一のクラスで実行できる単純なタスク (些細なことと言っているわけではありません) に抽象化のレイヤーを追加することです。
  • キャストはboost::variant_cast<>の代わりにによって実現されますdynamic_cast<>。
  • boost::any実装は簡単かもしれませんが、シリアル化は難しい方法になります。
于 2013-12-30T13:31:08.683 に答える