23

Boost のすべてのライブラリがヘッダーのみではないのはなぜですか? 別の言い方をすれば、.lib/.dll の使用が義務付けられている理由は何ですか?

クラスがテンプレートになれない場合、または静的フィールドがある場合ですか?

4

1 に答える 1

31

異なる点だと思います。

  • バイナリ サイズ。ヘッダーのみがクライアントにサイズの負担をかける可能性はありますか?
  • コンパイル時間。ヘッダーのみを使用すると、コンパイルのパフォーマンスが大幅に低下する可能性がありますか?
  • ランタイム パフォーマンス。ヘッダーのみで優れたパフォーマンスを実現できますか?
  • 制限。デザインにはヘッダーのみが必要ですか?

バイナリサイズについて。

そして少しのセキュリティ

ブースト ライブラリに到達可能なコードが多数ある場合、またはクライアントが到達可能かどうかをコンパイラが判断できないコードがある場合は、最終的なバイナリに配置する必要があります。(*)

パッケージ管理 (RPM または .deb ベースなど) を備えたオペレーティング システムでは、共有ライブラリはバイナリ配布サイズの大幅な削減を意味し、セキュリティ上の利点があります。セキュリティ修正はより速く配布され、すべての .so/ によって自動的に使用されます。 .DLL ユーザー。したがって、1 回の再コンパイルと 1 回の再配布がありましたが、N人の利益者がいます。ヘッダーのみのライブラリでは、修正ごとに N 回の再コンパイル、N 回の再配布があり、これらの N の一部のメンバーは、それ自体がすでに巨大です。

(*) ここで到達可能とは、「実行される可能性がある」ことを意味します

コンパイル時間について。

一部のブースト ライブラリは巨大です。ソースファイル#includeを少し変更するたびに、すべてを再コンパイルする必要があります#include。

これは、チェリーピックヘッダーで対策できます。

#include <boost/huge-boost-library.hpp> // < BAD
#include <boost/huge-boost-library/just-a-part-of-it.hpp> // < BETTER

しかし、本当にインクルードする必要があるものは、再コンパイルを妨げるほど十分に大きい場合があります。

対策は、静的ライブラリまたは共有ライブラリにすることです。これは、「(次のブースト更新まで) 1 回だけ完全にコンパイルする」ことを意味します。

実行時のパフォーマンスについて。

グローバルな最適化によって C++ のパフォーマンスの問題がすべて解決される時代にはまだ至っていません。コンパイラーが必要とするすべての情報を確実に提供するために、ヘッダーのみのものを作成し、コンパイラーにインライン化の決定をさせることができます。

その点で、CPU のキャッシングとスペキュレーションの問題により、インライン化が常に優れたパフォーマンスを提供するとは限らないことに注意してください。

また、この議論は、十分に頻繁に使用される可能性のあるブースト ライブラリに関するものであることに注意してください。たとえば、boost::shared_ptr<>非常に頻繁に使用されることが予想されるため、関連するパフォーマンス要因になります。

しかし、本当の唯一の関連する理由boost::shared_ptr<>はヘッダーのみであると考えてください...

制限について。

C++ のいくつかのもの、つまりテンプレートと列挙型はライブラリに入れることができません。

ただし、これは半分しか当てはまらないことに注意してください。タイプセーフでテンプレート化されたインターフェイスを実際のデータ構造とアルゴリズムに記述できます。これにより、ランタイム ジェネリックな実装がライブラリに含まれます。

同様に、C++ の一部はソース ファイルに配置する必要があり、ブーストの場合はライブラリに配置する必要があります。static基本的に、これは、一般的なメンバー変数やグローバル変数など、「複数定義」エラーを引き起こすすべてのものです。

いくつかの例は標準ライブラリにもあります:std::coutは標準で として定義されているextern ostream cout;ため、基本的にはそれを一度だけ定義する何か(ライブラリまたはソースファイル)coutの配布が必要です。

于 2012-07-06T13:37:12.367 に答える