問題タブ [header-only]

ヘッダーファイルのみで構成されるライブラリを開発しています。これまでのところ、クラスのみが含まれていますが、問題ありません。ただし、一部の関数を実装するには、ライブラリ内にライブラリ全体でアクセス可能な不変のデータ（つまり、クラスインスタンスデータではない）が必要になるようになりました。明らかに、グローバルデータをヘッダーファイルに入れることはできません。そうしないと、ヘッダーであるすべて#includeのコンパイルユニットにシンボルの定義があり、リンク時に複数の定義エラーが発生します。

static関数内のデータを変数にしてそのデータへのポインターを返すだけで、ライブラリにコンパイルユニットを追加しなくても、クラスに静的データを含めることができる回避策を見つけたようです。

これは正常に機能しているように見えますが、ヘッダーファイルstaticの関数の関数データが​​どうなるかわからないことを認めなければなりません。inlineこの「ハック」には、#includeこのヘッダーが独自のバージョンのを取得するすべてのコンパイルユニットなど、意図しない影響があるのではないかと思いarrayます。コンパイラはどのようにそしてどこにそれを置くことを決定しますか？

また、これをシングルトンアンチパターンなどの実装に使用していないことにも注意してください。複数の関数が使用する必要のあるデータを格納するために使用しているだけです（そのため、それを使用する関数だけに含めることはできませんがstatic、使用したとしても、同じ質問が表示されます）。

ヘッダーのみのライブラリの利点は何ですか?また、実装を別のファイルに入れるのに反対する方法でそれを書くのはなぜですか?

こんにちは、waf (1.7.5) に完全に移行する前に、次の構造の単純なプロジェクトを作成しようとしました。

これはルートwscriptです：

これは次のapplication wscriptとおりです。

これはlibrary1 wscript

(注: fortargetの代わりにを使用してみました。また、 の機能を有効にしようとしました。)namelibrary1cxx cxxshliblibrary1

これは次のmain.cppとおりです。

そして、これは私が得るエラーです:

ヘッダーを含める方法を変更したくありませんが、そのためには、プロジェクトの設定方法を変更する必要があるようです。

ご意見をお寄せいただければ幸いです。ありがとうございます。

EDIT：解決しました、それは単なるタイプミスでした（inludes代わりにincludesandexport_inludesの代わりにexport_includes）。

次のようなヘッダーのみのレイアウトで C++ アプリケーションをコーディングしたいと思っています。

唯一の cpp ファイルがメイン ファイルになります。残りのコードはヘッダー ファイルに配置されます。

このアプローチに何らかのパフォーマンス上の問題があるかどうかを知りたいです。クラス宣言でメソッドを定義するとインライン化されることはわかっていますが、cpp ファイルが 1 つだけになるため、インライン メソッドが重複することはありません。パフォーマンスに焦点を当てて質問したいだけです。拡張性、読みやすさ、メンテナンスなどについて話しているのではありません。このアプローチで、パフォーマンスの問題を引き起こす可能性のある何かが欠けているかどうかを知りたいです。

ありがとう！

約 450 ファイル (3.6 MB) のヘッダーのみの C++ コード ベース (VS 2010、Eclipse、Makefile) があります。コンパイル時間が長い (4 分) ため、毎日の作業が難しくなり始めました。そのわずかな部分 (約 20%) はテンプレート化されていますが、その他はいくつかのテンプレート メソッドをあちこちに持つ単純なクラスです。80% を別ファイルに移行することを考えてい.cppます.h。

まず、すべてのテンプレート ファイルを から.hに変更し.hppます。それは範囲を定義します。その後、私は大量の手作業を見るだけです。Visual Assist のMove implementation to source機能の助けを借りて、おそらく。最後に、部分的なユニティ ビルド (5..20.cppファイルのコンパイル単位) で考えていますが、それはすべての後に行うことができます。

約 360 個のファイルを手動で作業するよりも良い方法はありますか? スピードアップはありますか？

デフォルトではヘッダーのみではありませんNOLIBが、マクロを定義するヘッダーのみのライブラリとして使用できるC++ ライブラリを作成したいと考えています。

私は2つのアプローチを見てきました：

• インライン定義

foo.h

foo.cc

• 「人工」テンプレート

foo.h

foo.cc

これらのアプローチの長所と短所は何ですか? より良いオプションはありますか？

ヘッダーのみのライブラリを作成していますが、コンパイル中に表示される警告を取得したいと考えています。ただし、ライブラリを含む「メイン」プロジェクトの警告のみが表示され、ライブラリ自体の警告は表示されないようです。

含まれているライブラリの警告をコンパイラに強制的にチェックさせる方法はありますか?

MyHeaderOnlyLib.hppを使用して、CMakeスクリプトを介して見つけていfind_packageます。CMake によって実行されるコマンドを確認したところ-I、 ではなくが使用されてい-isystemます。

ライブラリを<...>（/usr/include/ディレクトリにある場合）またはローカルで"...".

#includeヘッダーのみの C++11/14 ライブラリを作成していますが、ライブラリ ファイル間のディレクティブをどのように処理すればよいかわかりません。

#includeユーザー指向のモジュール ヘッダー ファイルでできるだけ多くのディレクティブをグループ化する必要がありますか、それとも内部ファイルに必要なファイルを含める必要がありますか (同じインクルードを繰り返すこともあります)。

アプローチ A:

このアプローチでは、モジュール ヘッダー ファイルに必要なすべての依存関係が含まれてから、実装が含まれます。実装のヘッダー ファイルには、それ自体には何も含まれていません。

-

-

-

アプローチ B:

このアプローチでは、モジュール ヘッダー ファイルには実装ヘッダーのみが含まれます。実装ヘッダーに追加のインクルードが必要な場合は、ファイル自体が (再帰的に) インクルードされ、同じインクルードが繰り返されることがあります。

-

-

-

最善のアプローチは何ですか？

直感的には、同じインクルードを繰り返すことを避け、他のファイルの前にどのファイルをインクルードする必要があるかを明確にするため、アプローチ Aが最適だと思います。ただし、最大の欠点は、インクルード ディレクティブのない実装ファイルで、私の IDE ( QT-Creator ) で構文の強調表示が機能しなくなることです。

編集：

この質問は、 「意見に基づく」という理由で終了するように投票されました。ファイルを含む私のライブラリのような大規模なヘッダーのみのプロジェクトでは、多くのコンパイル時間がかかる可能性があるため、私は同意しません。したがって、アプローチ A はアプローチ B よりも速い場合もあれば、その逆の場合もあります。

現在ヘッダーのみのC++ ライブラリをいくつか作成しました。私のクラスのインターフェースと実装の両方が同じ.hppファイルに書かれています。

私は最近、この種のデザインはあまり良くないと考え始めました。

1. ユーザーがライブラリをコンパイルして動的にリンクしたい場合、それはできません。
2. コードの 1 行を変更するには、ライブラリに依存する既存のプロジェクトを完全に再コンパイルする必要があります。

私はヘッダーのみのライブラリの側面を本当に楽しんでいます#include.

両方の長所を活かすことは可能ですか? つまり、ユーザーがライブラリをどのように使用したいかを選択できるようにします。ばかげたコンパイル時間を避けるために「動的リンク モード」でライブラリに取り組み、パフォーマンスを最大化するために完成品を「ヘッダーのみモード」でリリースするので、開発もスピードアップします。

論理的な最初のステップは、インターフェイスと実装.hppを.inlファイルに分割することです。

とはいえ、先に進む方法はわかりません。多くのライブラリLIBRARY_APIが関数/クラス宣言の先頭にマクロを追加するのを見てきました.ユーザーが選択できるようにするために、おそらく同様のものが必要でしょうか?

「...の複数定義」エラーを回避するために、すべてのライブラリ関数にinlineキーワードのプレフィックスが付けられています。キーワードはファイル内のマクロに置き換えられると思いますか? マクロは、「ヘッダーのみモード」の場合は解決され、「動的リンク モード」の場合は何も解決されません。LIBRARY_INLINE.inlinline