アプリケーションレベルのコード用に「include」フォルダと「src」フォルダを分けていますか？
この質問は、主にUnix/LinuxスタイルのC++開発に関するものです。多くのC++ librariesは、ヘッダーファイルを「include」フォルダーに保存し、ソースファイルを「src」フォルダーに保存していることがわかります。準拠のために、私はこれを自分のコードで採用しました。しかし、これがapplicationコードに対しても行われるべきかどうかは、私には明確ではありません。フラットディレクトリ構造がそのために使用されるいくつかのケースを見てきました。推奨されるアプローチは何ですか？
私もそれらを分離していますが、厳密には拡張子ではなく、ファイルへのアクセスについてです。
顧客情報を管理し、これを行うためにCustomer、CustomerValidityCheckerの2つのクラスを使用するモジュールがあるとします。また、アプリケーションの他の部分はCustomerクラスについて知る必要があるだけであり、CustomerValidityCheckerは、何らかのチェックを実行するためにCustomerクラスによってのみ使用されると仮定します。これらの仮定に基づいて、私は次のようにファイルを保存します。
パブリックフォルダー（またはインクルードフォルダー）：
- customer.h
プライベートフォルダー（またはソースフォルダー）：
- customer.cpp
- customervaliditychecker.h
- customervaliditychecker.cpp
そうすることで、モジュールの呼び出し元にとって、アクセス可能な部分（パブリック）とアクセスできない部分がすぐに明らかになります。
Makefileを自動生成するビルドシステムがあります。それが行うことの1つは、サブディレクトリを再帰的に派生してライブラリとして構築し、それらをメインディレクトリのオブジェクトとリンクしてアプリケーションを作成することです。 （実際には、これらの「サブディレクトリ」は通常シンボリックリンクです。）ディレクトリ名が「.so」で終わっていない限り、ライブラリは静的です。これの良い点の1つは、多くの実行可能ファイルを含むシステムのフルビルドで、共通ライブラリを繰り返しコンパイルする必要がないことです。
ただし、この結果、ヘッダーとソースの分離はありません。そして、それは問題ではありませんでした。正直なところ、ヘッダーとソースファイルの場所には共通点があるため、この方法の方が良いと思います。また、ディレクトリを取得して、使用に必要なすべてのものを手に入れることができます。また、Subversionの「外部」機能や、他のVCSの同様の機能との相性も抜群です。
Include/srcの分離が失敗する最後の場所は、flex、bison、gengetoptsなどのコードジェネレーターを使用している場合です。これらのツールがどこに出力を配置するかを把握し、ビルドされるようにするのは、物事を広げている場合には注意が必要です。
ソースなしでコンパイルされた形で配布される可能性があるため、共有ライブラリ用にそれらを分離することは理にかなっています。 「プライベート」ヘッダーとソースファイルを同じディレクトリに残したまま、「パブリック」ヘッダー（プロジェクトまたはライブラリ外のコードからアクセスできるヘッダー）を分離するプロジェクトを見てきました。アプリケーションレベルで作成したものを、複数のユーザーが共有する下位レベルのライブラリにいつ変換したいかわからないため、共有ライブラリを作成する場合でも、アプリケーションレベルのコードを作成する場合でも、一貫したアプローチを使用することをお勧めします。プロジェクト。
多くは、関与するプロジェクトの規模に依存します。数十程度のファイルまで、それらを1つのディレクトリに保存する方が便利な傾向があります。数百または数千のファイルを含むより大きなアプリケーションの場合、それらを分離する方法を探し始めます（私が取り組んだプロジェクトでは、src/includeよりも機能的な行で行われていました）。それらの間で、それはおそらく疑問に思われます。
私はこれをしません。それにはほとんど利点がないようです。ヘッダーの拡張子はソースファイルとは異なる傾向があるため、本当に必要だと感じた場合はエディターに個別に表示させることができます-Visual Studioはデフォルトでこれを行いますが、一緒に表示することを好むので無効にします
私の見解では、どちらにも明確な利点はありません。私のエディター（Visual SlickEdit）が分離されていないときに偶然追加の参照機能を提供するため、プログラムとヘッダーファイルを一緒にしておくことにしました。
ほとんどの場合、ソースコードを分割するためにincludeおよびsrcフォルダーを作成します。フォルダーがすっきりし、IDEでファイルを見つけやすくなると思います。しかし、これは好みの問題だと思います。
どちらの方法も有効です。これは、これをどのように行うかを追跡したいコーディングスタイルによって異なります。
ボトムライン：変更されているソースとヘッダーは/srcに入ります。結晶化したコードは/libと/includeに入れる必要があります（実際には、.libsとその.hsをすべて/libに保持できます）。
- （a）このプロジェクトに固有であるか、（b）共有ライブラリとしてまだ除外されていない場合は、独自のソースとヘッダーを一緒にしてください。
- メインプロジェクトの特定のソースが（比較的安定した）ライブラリとして除外されたら、
.aまたは.libを/libに配置し、パブリックインターフェイスヘッダーを/includeに配置します。 。 - すべてのサードパーティライブラリとそれらのパブリックインターフェイスヘッダーも
/libと/includeに入ります。
他の人が指摘しているように、ツール/ IDEが1つのフォルダから.h/.cにアクセスする方が互換性があることがよくあります。ただし、組織の観点からは、変更するローカルコードを安定したlibコードから分離すると便利です。
インクルード（ヘッダー）とソースファイルを同じディレクトリ（フォルダー）に配置します。テーマごとに異なるフォルダを作成します。ヘッダーファイルを見つけようとすると、イライラします（デバッグ中および調査中）。一部のショップでは、ソースとインクルードの2つのフォルダーしかありません。これらのディレクトリは指数関数的に増加する傾向があります。コードの再利用はせいぜい悪夢になります。
私見、テーマ別に整理した方がいいと思います。各テーマフォルダーは、少なくとも1つのライブラリに組み込む必要があります。フォルダを検索または含めることで、さまざまなプロジェクトにテーマを簡単に含めることができます。プロジェクトに必要なのはライブラリのみです。スマートビルドエンジンは、テーマフォルダーを依存関係としてリストできます。これにより、ビルドプロセスが高速化されます。
テーマ編成は、プロジェクトに少し安全性を追加します。ファイルが別のディレクトリに配置されているため、ファイルへの偶発的な損傷（間違ったファイルの削除や別のバージョンへの置き換えなど）が軽減されます。 「Person」フォルダ内のファイルを削除しても、「Shape」フォルダ内のファイルには影響しません。
これは私の意見ですが、マイレージは異なる場合があります。
このルールを使用するビルドシステムがあります。このビルドシステムは sconspiracy SConsを構成するための一連のスクリプトで、C++の世界専用です。このツールを使用する例を見ることができます： fw4spl