用於應用程序級代碼的單獨「包含」和「src」文件夾？

這個問題主要涉及Unix/Linux風格的C++開發。我看到許多C++ 庫將它們的頭文件存儲在「包含」文件夾中，並將源文件存儲在「src」文件夾中。爲了符合我的要求，我在自己的代碼中採用了這一點。但是我不清楚這是否應該爲應用程序代碼完成。我見過一些使用平面目錄結構的情況。推薦的方法是什麼？用於應用程序級代碼的單獨「包含」和「src」文件夾？

來源

2010-05-27 StackedCrooked

我也把它們分開，但沒有嚴格的分機，但對文件的訪問。

假設你有一個管理客戶信息，並使用2類來完成這一模塊：客戶，CustomerValidityChecker。還假設應用程序中的其他部分只需要瞭解Customer類，並且CustomerValidityChecker僅由Customer類用於執行一些檢查。基於這些假設我將文件存儲到這樣的：

公共文件夾（或包含文件夾）：

customer.h

私人文件夾（或源文件夾）：

customer.cpp
customervaliditychecker.h
customervaliditychecker.cpp

這樣一來，它成爲你的模塊的調用者哪些部分是訪問的（public），哪一部分還不清楚。

來源

2010-05-27 19:11:16 Patrick

+1，我在工作中使用非常相同的分離。當你每天至少與十幾個組件進行交互時，用戶不用關心那些API文件就會很方便。 – 2010-05-28 06:49:18

我不知道它是否會影響建造時間。例如在Visual Studio的附加包含目錄中，使用包含較小文件夾的文件夾的情況下，通常會使文件比包含許多其他頭文件的文件夾更有趣，而該文件夾並不意味着被包含在庫之外？ – jxramos 2017-03-14 19:52:29

沒有明顯的優勢，要麼在我看來。我終於決定將程序和頭文件保存在一起，因爲我的編輯器（Visual SlickEdit）恰好在不分離時提供了額外的引用功能。

來源

2010-05-27 19:04:11

有趣的是，工具如何影響項目的許多方面。我同意以與IDE兼容的方式組織代碼通常是一個好主意。 – StackedCrooked 2010-05-27 20:07:32

我不這樣做;它似乎沒有什麼優勢。由於頭部往往有從源文件擴展名不同，你可以有你的編輯分別告訴他們，如果你真的覺得有必要 - Visual Studio的默認完成了這些，但我禁用它，因爲我喜歡看到他們在一起

來源

2010-05-27 19:05:39

圖書館的客戶有一個明顯的優勢：他們只需要知道一個包含目錄;這減少了維護開銷並降低了標題名稱衝突的風險......實施者也受益;他們可以改變他們的src目錄的佈局而不用擔心破壞庫客戶端。 – 2014-01-10 00:37:13

我幾乎總是創建include和src文件夾來分割我的源代碼。我認爲這會讓文件夾變得更加混亂，並且在我的IDE中更容易找到文件。但我認爲這只是一個品味問題。

這兩種方法都是有效的。這取決於你想要遵循的編碼風格。

來源

2010-05-27 19:10:21 Kungi

我的動機是類似的，我不喜歡雜亂。 – StackedCrooked 2010-05-27 20:03:03

在很大程度上取決於參與項目的大小。多達幾十個文件左右，將它們保存在一個目錄中往往會更方便。對於包含數百或數千個文件的更大的應用程序，您開始尋找將它們分開的方法（儘管在我所開發的項目中，它在功能上比src/include更多）。在這兩者之間，這可能是值得商榷的。

來源

2010-05-27 19:10:40

是的，這是當文件數量變大，我開始想要額外的組織。這很有趣，因爲它可能沒有太多好處。也許它只滿足於某種分類癡迷:) – StackedCrooked 2010-05-27 20:00:13

是有意義的他們共享庫分開，因爲它們可以以編譯的形式被分佈沒有源。我看到一些項目將「公共」標題（可以從項目或庫外的代碼訪問的標題）分離出來，同時將「私有」標題和源文件保留在同一目錄中。我認爲無論您是編寫共享庫還是應用程序級代碼，都使用一致的方法是很好的，因爲您永遠不知道何時將您在應用程序級寫入的內容轉換爲由多個項目。

來源

2010-05-27 19:11:29 bshields

我將include（header）和源文件放在同一個目錄（文件夾）中。我爲不同的主題創建不同的文件夾。當我試圖找到頭文件時（在調試和研究時），我感到沮喪。在一些商店中，只有兩個文件夾：來源和包含。這些目錄往往呈指數級增長。重用代碼充其量只是一場噩夢。

恕我直言，我相信按主題組織更好。每個主題文件夾應至少構建到一個庫中。不同的項目可以通過搜索或包含文件夾輕鬆包含主題。這些項目只需要包含這些庫。智能構建引擎可以將主題文件夾列爲依賴關係。這加快了構建過程。

主題組織還爲項目增添了一點安全感。由於文件位於不同的目錄中，文件的意外損壞（如刪除錯誤或替換爲不同版本）被減少。刪除「Person」文件夾中的文件不會影響「Shape」文件夾中的文件。

這只是我的看法，您的里程可能會有所不同。

來源

2010-05-27 19:26:52

這與我目前工作中的代碼庫類似。主應用程序由許多實用程序組成，每個實用程序都有自己的svn存儲庫。主要的信息庫通過svn externals收集所有信息。 – StackedCrooked 2010-05-27 20:05:20

我們有一個自動生成我們的makefile的構建系統。它所做的一件事是遞歸地下降任何子目錄並將它們構建爲庫，並將它們與主目錄的對象鏈接在一起以構建應用程序。（實際上，這些「子目錄」通常是符號鏈接。）除非目錄名以「.so」結尾，否則庫是靜態的。有一點非常好，就是我們的系統的完整版本有許多可執行文件，不需要重複編譯公共庫。

然而，由於這樣的結果，沒有標頭和源的分離。這從來都不是問題。老實說，我認爲這樣更好，因爲頭文件和源文件具有位置共同性，您可以抓取一個目錄，並知道您擁有了需要使用的所有內容。它也適用於Subversion的「外部」功能，以及其他VCS中的類似功能。

最後一個地方，一個包括/ src目錄分離失敗是如果你使用任何代碼生成器，如彎曲，野牛，或gengetopts。弄清楚這些工具應該把它們的輸出放到什麼位置，這樣，如果你把它們分散開來的話，它們的構建就會很棘手

來源

2010-05-27 19:40:12

老實說，我喜歡將頭文件和源文件放在一起。同樣在一個Visual Studio篩選器中，以便將頭文件和源文件放在一起。 – StackedCrooked 2010-05-27 19:56:15

我們有一個使用這個規則的構建系統。這個構建系統是sconspiracy一組腳本來配置SCons並專用於C++世界。你可以看到它使用這個工具的例子：fw4spl

來源

2010-05-28 07:08:57

底線：來源和標題仍處於/src改變去。已經結晶化/lib & /include（實際上你可以把所有.lib S和他們的.h S IN /lib）應該去規範。

將自己的源代碼和頭文件放在一起，只要它們（a）特定於此項目或（b）尚未作爲共享庫分解出來。
將主項目中的某些源作爲（相對穩定的）庫取出後，請將.a或.lib放入/lib，並將其公用接口標頭放入/include。
所有第三方庫及其公共接口標頭也會進入/lib & /include。

正如其他人注意，它往往是更兼容的工具/ IDE來從一個文件夾訪問.h/.c。但是從組織的角度來看，將穩定的lib代碼與不斷變化的本地代碼分開是有用的。

來源

2015-07-23 07:49:01

用於應用程序級代碼的單獨「包含」和「src」文件夾？

回答

相關問題