C ++プロジェクトのソースコードのレイアウト

StackOverflow https://stackoverflow.com/questions/900240

質問

プロジェクトディレクトリを整理する一般的な方法の一つは、このような多かれ少なかれあります：

MyLib
     +--mylib_class_a.h
        mylib_class_a.cpp
        mylib_library_private_helpers.h
        mylib_library_private_helpers.cpp

MyApp
     +--other_class.h
        other_class.cpp
        app.cpp

app.cppます：

#include "other_class.h"
#include <mylib_class_a.h> // using library MyLib

同じライブラリのすべての.hと.cppファイルが同じディレクトリにあります。名前の衝突を避けるために、ファイル名には、多くの場合、会社名および/またはライブラリ名で接頭されています。 MYLIBは、私は接頭辞のファイル名のファンではないんだけど、私は#include見てのアイデアが好きで、そのヘッダファイルが属している場所を正確に知っているなどのMyAppのヘッダ検索パスになります。私は、ファイルを整理するこのアプローチを嫌いではありませんが、私はもっと良い方法があるはずだと思います。

私は新しいプロジェクトを始めているので、私はいくつかのディレクトリ組織のアイデアを募集したいと思います。現在、私は、このディレクトリ構造を好むます：

ProjA
    +--include
             +--ProjA
                    +--mylib
                           +--class_a.h
                    +--app
                           +--other_class.h
    +--src
         +--mylib
                +--class_a.cpp
                   library_private_helpers.h
                   library_private_helpers.cpp
         +--app
              +--other_class.cpp
                 app.cpp
                 util.h

app.cppます：

#include "util.h" // private util.h file
#include <ProjA/app/other_class.h> // public header file
#include <ProjA/mylib/class_a.h> // using class_a.h of mylib
#include <other3rdptylib/class_a.h> // class_a.h of other3rdptylib, no name collision
#include <class_a.h> // not ProjA/mylib/class_a.h
#include <ProjA/mylib/library_private_helpers.h> // error can't find .h

.cppファイルとプライベート（即時ライブラリにのみ表示）.hファイル（srcがその時々のlibと呼ばれている）srcディレクトリの下に格納されています。公開ヘッダファイルには、プロジェクト/ libディレクトリ構造に編成し、<ProjectName/LibraryName/headerName.h>経由含まれています。ファイル名は何が付いていません。私が今まで他のチームによって使用されるようにMYLIBをパッケージ化するために必要な場合は、私は単純に適切なバイナリファイルをコピーするために私のメイクファイルを変更することができ、全体を/ ProjAディレクトリが含まれます。

ファイルをソース管理にチェックインされており、人々がそれらの作業を開始すると

ディレクトリ構造を変更することは難しいでしょう。権利を取得、行くで取得することをお勧めします。

このような経験を組織し、ソースコードをお持ちの方？あなたはそれについて好きではない何か？あなたがそれを行うには良い方法を持っている場合は、私は非常にそれについて聞きたい。

役に立ちましたか？

解決

まあ、それはすべてのこれらのプロジェクトはどのようにビッグに依存します。あなただけのいくつかのファイルを持っている場合は、1つのフォルダにそれらをすべて打つます。

あなたが管理するために多くのファイルを持っていないあまりにも多くのフォルダは、私の意見のやり過ぎです。それはあなたがそれらだけでいくつかのファイルを持っているときにあるとフォルダのうち迷惑な掘削を取得します。

また、このようなものを使っている人に依存します。あなたはライブラリを書いていると、その、他のプログラマが使用するつもりなら、それは彼らが含まフォルダに使用したいヘッダを整理するために良いことです。あなたはライブラリの数を作成し、それらのすべてを公開している場合は、あなたの構造がうまくいくかもしれません。彼らは独立したライブラリだし、開発はすべて一緒に行って、彼らはバージョン管理と異なる時間に解放されませいる場合しかし、あなたは一つのフォルダ内に配置可能な一つのプロジェクトのすべてのファイルを持って付着したほうが良いと思います。

実際には、私はあなたがやったようなフォルダにソースを分割する巧妙な仕組みに再編成、その後、あなたはそのunmanagableを見つけるポイントに到達するまで、1つのフォルダにすべてのものを維持すると言うでしょう。あなたは、おそらくそれはあなたがに実行する問題から整理する必要がある方法を知っているでしょう。

KISSは通常、常にプログラミングでのソリューションです - >できるだけ単純にすべてを保つ

。

他のヒント

なぜ最初のような何かをしていない、唯一の愚かな接頭辞を減らすincludeディレクティブの一部としてMyLibが中に存在することのディレクトリを使用します 

#include <MyLib/ClassA.h>

これどこからどこを示しています。私は、ヘッダーまたはソースファイルを開いていて、他のを見つけて、それを開くために、ディレクトリ構造を介してナビゲートする必要がある場合に、第2の選択肢として、私は個人的には本当にイライラ。あなたはsrc/mylib/class_a.cpp開いていた、とヘッダを編集したい場合は、あなたの第二の例では、多くのエディタであなたは、ヘッダーを見つける前に、その後include/ProjAに、2つのレベルが戻って行かなければならないと思います。そして、どのように我々は、ヘッダは、いくつかの他の外部手がかりなしProjAサブディレクトリにあることを知っていますか？プラス、それは「より良い」とは、それが別のファイルを移動させずに、どのように使用されるかを表していることを別の場所に移動し得るために、一つのファイルまたは他のためにあまりにも簡単です。それはちょうど私が私が私の仕事でそれに遭遇したときに頭痛与えます（と、私たちは、人々が私はちょうど言及したすべての潜在的な問題をした私たちのコードベースのいくつかの部分を持っている）。

私は両方の方法を試してみました。個人的に、私は最初の方が好き。私は、より特定のディレクトリにすべてをかけるための衝動を理解し、それが過剰合併症の多くを引き起こします。

私は通常、このルールを使用する：アプリケーションと社内ライブラリは、最初のメソッドを使用します。公共のオープンソースのライブラリは、第二の方法を使用します。あなたがコードをリリースしている場合は、インクルードファイルが別のディレクトリにある場合、それは多くのことができます。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top