ヘッダーの ../include/header.h などの相対パスの利点は何ですか?

ヘッダー ファイルがどの名前空間またはモジュールに属しているかが非常に明確になるので、私はパス構文を好みます。

#include "Physics/Solver.h"

すべてのモジュールがヘッダー ファイルの前に名前を付ける必要がなく、非常に自己記述的です。

ただし、「..」構文を使用することはほとんどありません。代わりに、プロジェクト インクルードで正しいベース ロケーションを指定します。


#include "../include/header.h" の問題点 多くの場合、偶然に機能し、一見無関係な変更が後で機能しなくなるということです。

たとえば、次のソース レイアウトを考えてみましょう:

./include/header.h
./lib/library.c
./lib/feature/feature.c

そして、インクルード パス -I. -I./lib でコンパイラを実行しているとしましょう。 .

  • ./lib/library.c #include "../include/header.h" ができます 、これは理にかなっています。
  • ./lib/feature/feature.c #include "../include/header.h" もできます 、たとえそれが意味をなさないとしても。これは、コンパイラが #include を試みるためです。 現在のファイルの場所に相対的なディレクティブであり、それが失敗した場合は #include を試行します 各 -I に対するディレクティブ #include のエントリ

さらに、後で -I./lib を削除すると、 #include から パス、その後 ./lib/feature/feature.c を壊します .

次のようなものが望ましいと思います:

./projectname/include/header.h
./projectname/lib/library.c
./projectname/lib/feature/feature.c

-I. 以外のインクルード パス エントリは追加しません 、そして両方 library.cfeature.c #include "projectname/include/header.h" を使用します . 「projectname」が一意である可能性が高いと仮定すると、ほとんどの状況で名前の衝突やあいまいさが発生することはありません。インクルード パスや make の VPATH を使用することもできます 絶対に必要な場合にプロジェクトの物理レイアウトを複数のディレクトリに分割する機能 (たとえば、プラットフォーム固有の自動生成コードに対応するため。これは #include "../../somefile.h" を使用すると本当に壊れるものです) ).


IANALL、でも .. を入れるべきではないと思います は、移植性がなく、標準でサポートされていないため、実際の C または C++ ソース ファイルにあります。これは \ を使用するのと似ています は Windows 上にあります。コンパイラが他の方法で動作しない場合にのみ行ってください。