問題タブ [header-only]

クライアントが使いやすいように、作業中のライブラリをヘッダーのみのライブラリとしてパッケージ化したいと思います。（これは小さく、別の変換ユニットに配置する理由は実際にはありません）ただし、これはC ++の単一定義規則に違反するため、コードをヘッダーに単純に配置することはできません。（ライブラリヘッダーがクライアントプロジェクトの複数の翻訳ユニットに含まれていると仮定します）

ライブラリを変更してヘッダーのみにする方法はありますか？

ここにかなりのコードをインライン化する必要があったようです。これを次のようなヘッダーファイルに完全に残すのは悪い設計慣行ではないかと思います。

すべてをヘッダーファイルだけに保持することが不可能なような依存関係のパターンはありますか？ヘッダーごとに1つのクラスのルールのみを適用した場合はどうなりますか？

この質問の目的のために、静的なものを無視しましょう:)

ヘルパー関数のヘッダーのみのライブラリを自分で作成しようとしています。（私はブーストとSDLを使用していますが、ブーストの方がはるかに使いやすいので、自分のヘルパーライブラリ用にそれをエミュレートしたいと思います。）

クラスの1つで「タイプに名前を付けていません」というエラーが表示され、混乱します。スペルミスまたは循環インクルードでこの問題が発生する可能性があることはわかっていますが、コードでこれらの問題のいずれも見つかりません。SdlWindow.cppでの前方宣言は役に立ちません。ヘッダーを再度インクルードする（つまり、/ do /に循環インクルードを含める）ことも役に立ちません（「以前に定義された」エラーが発生します）。

Main.cpp：

SdlWindow.hpp：

そしてSdlWindow.cpp：

私が得るエラーは、SdlWindow.cppの「SdlWindow'は型に名前を付けていません」です。ここで、2つのSdlWindow関数を宣言します。これを引き起こしているのは何ですか？どうすれば修正できますか？

WindowsVistaのEclipseでmingw32のgccをコンパイルしています。

明らかに、テンプレート ライブラリはヘッダーのみである必要がありますが、非テンプレートの場合、いつヘッダーのみにする必要がありますか?

このプロジェクト (http://www.savarese.com/software/libssrccdtree/) を見ると、「C++ ヘッダーのみのテンプレート ライブラリ」という定義が見つかりました。現時点では、基本的な C++ の知識はありますが、これが正確に何を意味するのか、なぜこのプロジェクトでこの人々がそれを使用するのかを知りたいと思っています。

.hと.cppに分離せずに.hppでコードを記述したい

• やったよ。静的クラスフィールドの定義にのみ.cppを使用します

#includeを手動で書きたくない...

• 可能な場合は前方遅延を使用します。
• すべての.hppファイルには#pragmaが1回含まれています。
• しかし、私のプロジェクトが40〜50クラスに成長すると、インクルードグラフの問題が発生しました。定義に誤りがあります。

プロジェクトモデル（mvcの一部など）のインクルードグラフが添付された画像。
私はこのアプリをグラフ生成に使用しました（MSVSがなくても動作します！）。

インクルードグラフはどのように見えるべきですか？木のように？
C＃やJavaのように、インクルードを手動で記述しない方法はありますか？

私はかなり大きな C++ サポート ライブラリを開発しており、ヘッダーのみのアプローチに移行していることに気付きました。C++ では、クラスで定義した場所を実装できるため、これはほとんど機能します。テンプレート化されたメソッドの場合、実装はとにかく同じファイルにある必要があるため、実装を定義とともに保持する方がはるかに簡単であることがわかりました。

ただし、「ソース」を使用しなければならない場合が数回あります。ほんの一例として、循環依存が発生することがあり、実装をクラス定義の外に記述する必要があります。これが私がそれをどのように扱っているかです：

次に、libfoo を使用するプロジェクトは、main.cpp で次のことを行います。

その他の .cpp では:

ポイントは、compile-inline セクションが (main.cpp で) 1 回だけコンパイルされることです。

そして最後に私の質問: このイディオムまたはこのように機能する他のプロジェクトの名前はありますか? テンプレート化とクラスメソッドによって実装と定義がぼやけているのは当然の結果のようです。そして、これが悪い考えである理由や、うまくスケーリングできない可能性がある理由はありますか?

余談ですが、多くのコーダーは、正当な理由で、ヘッダーが実装ではなくインターフェイスに似ていることを好むことを知っていますが、プライベートメンバーをすべて一緒に隠すのが好きなので、IMHOドキュメントジェネレーターはインターフェイスの記述に適しています:-)

クラス ユーザーにメンバーを定義する負担をかけずに、テンプレート化されていないライブラリ クラスに静的メンバーを配置する最善の方法は何ですか?

このクラスを提供したいとします。

次に、クラスのユーザーは、静的メンバーをどこかに定義することを忘れてはなりません (すでに何度も回答 されているように):

以下に答えがありますが、いくつかの欠点があります。より優れた、および/またはよりエレガントなソリューションはありますか?

私はSOを使用してこれに対する答えを見つけようとしました。C ++でヘッダーのみのライブラリを構築することのさまざまな長所と短所をリストした質問がいくつかありますが、定量化できる用語でそうするものを見つけることができませんでした。

それで、定量化可能な用語で、従来分離されたc ++ヘッダーと実装ファイルを使用することとヘッダーのみを使用することの違いは何ですか？

簡単にするために、テンプレートは使用されていないと仮定します（ヘッダーのみが必要なため）。

詳述するために、私は記事から私が見たものを賛否両論としてリストしました。明らかに、一部は簡単に定量化できないため（使いやすさなど）、したがって定量化可能な比較には役に立ちません。定量化可能なメトリックを期待するものに（定量化可能）のマークを付けます。

ヘッダーのみの長所

1. ビルドシステムでリンカーオプションを指定する必要がないため、含める方が簡単です。
2. ライブラリの関数はコードにインライン化されるため、常にすべてのライブラリコードを残りのコードと同じコンパイラ（オプション）でコンパイルします。
3. それははるかに速いかもしれません。（定量化可能）
4. コンパイラー/リンカーに最適化のより良い機会を与える可能性があります（可能であれば説明/定量化可能）
5. とにかくテンプレートを使用する場合は必須です。

ヘッダーのみの短所

1. それはコードを膨らませます。（定量化可能）（実行時間とメモリフットプリントの両方にどのように影響しますか）
2. コンパイル時間が長くなります。（定量化可能）
3. インターフェイスと実装の分離の喪失。
4. 循環依存関係を解決するのが難しい場合があります。
5. 共有ライブラリ/DLLのバイナリ互換性を防ぎます。
6. これは、C++の従来の使用方法を好む同僚を悪化させる可能性があります。

大規模なオープンソースプロジェクト（同様のサイズのコードベースを比較）から使用できる例は、非常にありがたいです。または、ヘッダーのみのバージョンと分離されたバージョンを切り替えることができるプロジェクトを知っている場合（両方を含む3番目のファイルを使用）、それが理想的です。逸話的な数字は、私が洞察を得ることができる球場を私に与えるので、また役に立ちます。

長所と短所のソース：

• https://stackoverflow.com/a/6200793/278976
• https://stackoverflow.com/a/1783905/278976

前もって感謝します...

アップデート：

後でこれを読んでいて、リンクとコンパイルに関する背景情報を少し知りたいと思っている人にとって、私はこれらのリソースが役立つと思いました。

• http://www.amazon.com/Computer-Systems-Programmers-Perspective-Edition/dp/0136108040の第7章
• http://www.yolinux.com/tokyoS/LibraryArchives-StaticAndDynamic.html
• http://www.cyberciti.biz/tips/linux-shared-library-management.html

更新:(以下のコメントに応えて）

答えが異なるかもしれないからといって、測定が役に立たないという意味ではありません。ある時点で測定を開始する必要があります。そして、あなたが持っている測定値が多ければ多いほど、画像はより鮮明になります。この質問で私が求めているのは、全体の話ではなく、全体像を垣間見ることです。確かに、偏見を非倫理的に促進したいのであれば、誰でも数字を使って議論を歪めることができます。しかし、誰かが2つのオプションの違いに興味があり、それらの結果を公開する場合、情報は役立つと思います。

誰もこのトピックに興味がなく、それを測定するのに十分ですか？

シュートアウトプロジェクトが大好きです。これらの変数のほとんどを削除することから始めることができます。1つのバージョンのLinuxで1つのバージョンのgccのみを使用してください。すべてのベンチマークに同じハードウェアのみを使用してください。複数のスレッドでコンパイルしないでください。

次に、以下を測定できます。

• 実行可能サイズ
• ランタイム
• メモリフットプリント
• コンパイル時（プロジェクト全体と1つのファイルの変更の両方）
• リンク時間