10

C/C++ を使用しているときに、.h ファイルを .cpp/.c ファイルに含めるときに #include ディレクティブのファイル パスを処理するさまざまな方法に遭遇しました。Google スタイル ガイドでは、#include でファイル パスの一部を使用することをほのめかしています。そうは言っても、私は現在、コードを「継承」したときに適切にレイアウトされた Makefile (G++ 用) と構造がレイアウトされたプロジェクト (小さなプロジェクトではありますが) に取り組んでいます。つまり、/project_name という名前のディレクトリがあり、その中に Makefile といくつかのサブディレクトリがあります。たとえば、/project_name/inc は .h ファイルを保持し、/project_name/src は .cpp ファイルを保持します。Makefile は、各サブディレクトリを調べてソース コードをコンパイルするように設定されています。

私の質問は、ディレクトリ構造と Makefile を考えると、#include の「推奨される」方法は何かということです。私が使用して成功した 2 つの代替手段を以下に示します。

  1. include "mycode.h" // パスの知識はなく、私が説明した構造を想定しています

  2. include "../../project_name/inc/mycode.h" // 少し複雑に見えますが、ファイル構造がよくわかります

私が見逃している他のオプションはありますか？

4

5 に答える 5

2

これは主観的な回答です。両方が機能する場合は両方とも正しいですが、ソース コード内のソース ツリーの知識はなく、プロジェクト設定/Makefile だけであることが望ましいので、最初のオプションが最適です。

#include "mycode.h"
于 2013-06-12T07:56:31.263 に答える
2

trojanfoe が言うように、それは非常に主観的なものですが、それでも私は以下のスタイルを採用します。

#include "mycode.h"

.cpp/.h ファイルを含むフォルダーを再構築する必要がある場合、以下のスタイルは壊れやすく、失敗する運命にあります。.cpp ファイルを変更して、正しい相対パスを指定する必要があります。

#include "../../project_name/inc/mycode.h" //
于 2013-06-12T08:03:31.007 に答える
0

#include(つまり、option2) にコード構造を含めると、コードの移植性が低下するようです。

私は最近、IOS によって消費されるコンポーネント (ジャムで構築されたもの) を cocoapod に持ち込むときに問題に遭遇しました。主な問題は、コードに次のコードがあることです

`#include <impl/xxxxx.h>`

ココアポッドに持ち込むと、「impl」のパスが認識されず、その設定が見つからなかったため、コンパイルされません（私は間違っています。今得たものを共有してください）。への変更

`#include "impl/xxxx.h" `

このポッドのコンパイルは成功しますが、クライアントにはまだ使用されません。sicne クライアント コードには、「impl」構造についての知識がありません。

オプション1を使用するようになるこのソース構造インクルードをすべて削除することになります..

だから私のポイントはそれです。1) パブリック ヘッダーの場合、インクルード ソース構造を避けます。2) プライベート ヘッダー/コードの場合、"private/source/structure/xxxx.h" を使用してコンパイル設定を簡単にします。

何かあれば私と共有してください。

于 2015-08-11T02:43:34.467 に答える