公共ヘッダの非暴露のタイプを使用することのリスクは、私がそのパブリックインターフェイスクラスの1のように定義されたライブラリ開発しています

Question

どのようなものです：私は再び、ホイールを再発明していますことを、ここで考えて

class speed: 
public: 
    //constructors, operators, setter, getters... 
private: 
    float x,y,z; 
}; 

を。普通のfloat x,y,zの代わりにEigen::vector3f（または他の既知の第3のライブラリの代わりのもの）をプライベートメンバー変数として使用すると、すべてのコーナーのケースを処理するすべての演算子演算子を書き直すよりはるかに優れています。

同時に、私は自分のライブラリに第三者を公開したくない（これは私が満たす必要がある）。

Eigen::vector3fまたはその他のうまく設計されたフロートベクトルを宣言し、適切なスマートポインタ内で使用することは賢明でしょうか？ご意見・ベースの質問のスタイルではないトラップするに

：

• は、このアプローチを使用して、任意のリスクの可能性はありますか？
• データが動的に割り当てられているため、理論的にはパフォーマンスが低下しますか？

Answer 1

これはソフトウェアエンジニアリングの問題であり、その答えは意見に基づいている可能性が最も高いです。

私の提案：

はspeedオブジェクトを指定してEigen::vector3fを返す関数を提供します。その関数がメンバ関数であるか非メンバ関数であるかはセカンダリですが、非メンバ関数が望ましいです。

floatまたはEigen::vector3fの3つを使用して内部データを保存するかどうかは重要ではありません。

この方法を使用すると危険性はありますか？

私は何も表示されません。しかし、どのプロジェクトでもEigen::vector3fは使用していません。リスクアセスメントで目標を外れているかもしれません。

データが動的に割り当てられるため、理論的にパフォーマンスが低下しますか？

私はなぜそうは思わないのですか？ speedオブジェクトを動的に割り当てる場合、そのような割り当てのコストは、3つのfloatを格納するか、またはEigen::vector3fをメンバ変数として格納するかには関係ありません。

Answer 2

幾分重い機械（Eigen::vector3f）とメンテナンスの労力（pimplイディオムを実装する）を増やしてホイールを再改造するコストを検討しています。アプリケーションが基盤となる機械を気にしない場合は、Eigen::vector3fをBoost.Unitsまたは他の特殊なライブラリと交換することができます.pimplイディオムが適切かもしれません。 QtのようなOSIライセンスのプロジェクトのライセンスに準拠しなければならないクローズドソースアプリケーションをお持ちの場合、これはさらに真実です。利点は、法的な理由やプロジェクトがもはや使用可能/使用不能になったために将来的に切り替える必要がある場合、pimplイディオムがそれを容易にするということです。

パフォーマンス低下の場合、は、メモリ使用量/割り当ての増加/コンパイラが最適化する能力を低下させます。しかし、これらは仮説的です。他の状況と同様に、知る唯一の方法は測定/ベンチマークです。物理学を扱うアプリケーションが他の分野でボトルネックを起こす可能性がはるかに高いことがわかります。