問題タブ [header-only]

少し前に、XCode を使用して C++1x で大きなヘッダー ライブラリを開始しました。ライブラリの現在のレイアウトは () のようなものです (からの部分的な出力ls -R sponf)

このプロジェクトを CLion に移植したかったのですが、これは (同様の AndroidStudio IDE に基づく) 非常に優れた IDE のようですが、いくつかの問題が発生しています。

小さなテストプログラム

テストとしてこの小さなプログラムを試しました：

プログラムはコンパイルされ、正常に実行されます。ただし、CLion はspaces名前空間 (子ファイルの 1 つで宣言されている) も名前空間も認識しませんsimulations。それらは両方とも赤でマークされており、それらのコンテンツを検査したり、定義に移動したりすることはできません⌘</kbd>-clicking, etc. etc...

ライブラリの関連部分

"sponf.h"調べてみると

("sponf_children.h"最上位レベルの の隣にあり"sponf.h"ます) で、

各「子」ヘッダーには、対応する「祖先」または「カテゴリ」ヘッダー (「子」自体のスーパークラスを定義する) が含まれます。

CLionの反応

すべてのサブディレクトリとヘッダーを簡単に見つけるオートコンプリート予測にもかかわらず、この最後のファイルのすべてのインクルード ディレクティブは赤くマークされ、⌘</kbd>-clicking on any of them leads to a popup message

移動する宣言が見つかりません

エディターの右側のリボンは、次のような多くのエラーを通知します

',' または ) が必要です

） 期待される

宣言子が必要です

期待する型

ない ;

予期しないシンボル

これは、各 include ステートメントで同じではありません (それぞれが 2 つからこれらすべてのエラーを生成します)。

一方、CLion は、Eigenほとんど同じ構造を持つすべてのヘッダーを完全に見つけることができます!

両方のライブラリを入れて、それに応じ/opt/local/includeて変更しましたCMakeLists.txt

CLion がプロジェクト構造を適切に解析できないのはなぜですか? XCode を env に含め/opt/local/include/sponfた/opt/local/include/eigen3後HEADER_SEARCH_PATHS。プロジェクトの変数は、まったく同じプログラムをコンパイルしながら、任意のヘッダーを見つけることができます。

他に知っておくべきことはありますか？私のやり方が間違っているのでしょうか、それとも CLion がまだ成熟しておらず、これはただの残念なバグなのでしょうか? これは、CLion と CMake ツールチェーンへの私の最初のアプローチなので、それに関するあらゆる種類の情報を大歓迎します!

非常に長い質問で申し訳ありませんが、それ以上縮小することはできませんでした... よろしくお願いします。

github などにある典型的な C++ ヘッダーのみのライブラリについては、次の場所にありますhttps://github.com/username/library_name。

include/library_name次のようなフォルダーを持つディレクトリ構造があります。

• include/library_name

すべてのライブラリ ソースが含まれています。これは通常、ユーザーによって、たとえば Linux の場合にインストールされます/usr/local/include/library_name。

ライブラリを外部プロジェクトでポータブルに使用するための cmake スクリプトが必要です (Linux、MacO、BSD、Windows 間)。

そうすべき：

• ライブラリがインストールされているかどうかを確認し、バージョンがしきい値を超えている場合は、インストールされているライブラリを使用します

• それ以外の場合は、github からライブラリを取得し、それを外部プロジェクトとして構成し、システム インクルード パスに配置して、インストールされているかのようにプロジェクトで使用できるようにします。

CMakeでこれを達成する正しい方法は何ですか?

ヘッダーのみのライブラリ ( thread-pool ) をサブ プロジェクトとして使用しようとしています。だからルートCMakeLists.txtで私は持っています

中身thread-pool/CMakeLists.txt

これはソースのないヘッダーのみのライブラリであるため、エラーが発生します。

CMake エラー: CMake はターゲットのリンカー言語を判別できません: スレッドプール

1つの解決策は使用することですADD_LIBRARY(thread-pool INTERFACE)が、それはCMakeでのみ機能し、3.02.8がインストールされています。CMake を 3.0 にアップグレードする方法についての解決策を求めているわけではありませんが、何かありますalternative way that I can use with CMake 2.6 or 2.8か?

私の頭に浮かぶ1つの方法は、ダミーの機能を備えた偽のcppファイルを用意して、それをソースに入れることですが、それは悪い解決策になります。

my_template_library.hで使用する必要がある場合、私のプロジェクトはこの設定に似ていますmain_class.h。

main.cpp

main_class.h

main_class.cpp

my_template_library.h

.h私が書いたテンプレートヘッダーのみのライブラリでは、最初にクラス内のすべてを宣言してから、クラスをと.cppコードに分離するときに通常行うように、クラスの外側にすべてを定義しますが.cpp、 の最後にファイルが追加され、.hインクルード内に警備員。テンプレート ライブラリが 1 回だけ含まれている限り、これは問題なく機能しましたが、それ以上のものが含まれるようになると、非常に紛らわしい問題が発生しました。

何が起こっているのか混乱しています。これを理解するために my_template_library.h にを追加しました#pragma message。これはコード内でコメントアウトされています。コメントを外してコードを実行すると、

したがって、ヘッダー ファイルは次の方法でインクルードされます。

1. main.cpp -> main_class.h
2. main_class.h
3. main_class.cpp -> main_class.h
4. my_template_library.h (単独で?)

だから、私の質問は次のとおりです。

1. インクルードガードが役に立たないのはなぜですか?
2. これを防ぐにはどうすればよいですか？

すべてをヘッダーのみにする代わりにソース ファイルを使用する場合、C++ のヘッドのみのライブラリで循環依存関係の問題が発生します。これは循環依存の問題ではありません。

状況は次のようになります。

A と B の 2 つのクラスに対して 4 つのファイルがあります。すべてのクラスには、ヘッダー ファイル ("A.hpp" など) と実装ファイル ("A.tpp" など) があります。

依存関係は次のとおりです。

• A のヘッダーには B' ヘッダーが必要です
• A の impl には B のヘッダーが必要です
• B のヘッダーには、A への前方宣言のみが必要です。
• B の impl には A のヘッダーが必要です

したがって、ソースベースのライブラリでは、次のソース ファイルのインクルードとコンパイルの順序で問題ありません。

• B.hpp
• A.hpp
• A.tpp または B.tpp (ここでの順序は重要ではありません)

私のファイルは次のように構成されています。

A.hpp のファイル コンテンツ:

A.tpp のファイル コンテンツ:

B.hpp のファイル コンテンツ:

B.tpp のファイル コンテンツ:

私の質問は次のとおりです。ライブラリにヘッダーのみのソリューションを使用しているためにのみ発生する、この不必要な循環依存を解消するソリューションはありますか?