包含所有內容，用「使用」分開

我正在開發一個C++庫。這讓我想到了Java和C＃處理包含庫的不同組件的方式。例如，Java使用「導入」來允許使用其他包中的類，而C＃只是使用「使用」來導入整個模塊。包含所有內容，用「使用」分開

我的問題是，將庫中的所有內容包含在一個大型包含中，然後使用using指令導入特定的類和模塊會是一個好主意嗎？或者這只是瘋了嗎？

編輯： 良好的反應，到目前爲止，這裏有一些緩解因素，我覺得到這個念頭：

1）內部的#includes保持正常（短和對點）
2）的文件，其中包括一切任選庫提供給那些誰願意使用它
3）你可以任意讓大包括預編譯頭文件的一部分

2011-03-01 Dave

如果您限定名稱，例如'new java.util.LinkedList （）'，您可以使用Java *中不帶*進口的其他包中的類。 Java的'import'更像C++的''using''，Java沒有任何類似於C++''include'預處理指令的東西。 – fredoverflow 2011-03-01 08:47:32

您在C++中混淆了#include語句的用途。它們的行爲不像Java中的import語句或在C＃中使用語句。 #include做了什麼;即加載並解析整個指示文件作爲當前翻譯單元的一部分。單獨包含的原因是不必花費編譯時間解析每個文件中的整個標準庫。相反，您試圖使#include表現得像這樣的陳述僅僅是爲了程序員組織的目的。

#include是用於管理編譯過程;不用於分離用途。（事實上，你不能使用單獨的頭來強制單獨使用，因爲這樣做會違反一個定義規則）

tl; dr - >不，你不應該那樣做。 #include儘可能少。當你的項目變大時，當你沒有等待幾個小時來編譯你的項目時，你會感謝你自己。

來源

2011-03-01 05:24:29

+1爲tl; dr :) – 2011-03-01 05:27:21

您提出了一些優點。我將我的評論添加到編輯部分。但是，我會告訴你一個很好的舊Windows.h，你最終只能使用一小部分，但卻被迫將所有的東西都包括在內，這使得編譯需要更長的時間。 – Dave 2011-03-01 05:57:53

@Dave：我不能多說''這麼大頭的原因。不過，我相信其原因是因爲它允許重構Windows SDK中的頭文件而不破壞客戶端程序。（例如，Vista的SDK經歷了大量的頭文件更改，但用戶程序'#include '仍然編譯得很好。） – 2011-03-01 15:23:11

我個人建議只有在需要他們明確顯示您的文件需要哪些功能時才包含標題。同時，這樣做會阻止您獲得您可能不需要的功能，例如與文件目標無關的功能。當然，這沒什麼大不了的，但我認爲當你無法訪問不必要的函數/類時，維護和更改代碼會更容易;它只是使它更直接。

來源

2011-03-01 05:15:15

我可能會因此而失望，但我認爲你會提出一個有趣的想法。這可能會減慢編譯速度，但我認爲這個概念很整潔。

只要你謹慎地使用了using--只爲你需要的命名空間 - 其他開發者可以通過瀏覽頂部來了解文件中使用了哪些類。它不會像看到一個#include d文件列表一樣細緻，但看到包含的頭文件列表真的非常有用嗎？我不這麼認爲。

只要確保所有頭文件都使用inclusion guards，當然。 :)

來源

2011-03-01 05:19:37 ClosureCowboy

正如@Billy ONeal所說，最重要的是#include是一個預處理程序指令，它會導致代碼的「^ C，^ V」（複製粘貼），從而增加編譯時間。

C++中最好考慮的策略是在「.h」文件中轉發聲明所有可能的類，並將它們包含在「.cpp」文件中。它隔離了依賴關係，因爲如果從屬包含文件發生更改，C/C++項目將被級聯重建。

當然，M $編譯器及其預編譯頭文件往往會做相反的事情，並附上您的建議。但是任何試圖在這些編譯器上移植代碼的人都非常清楚它是如何發臭的。

像Qt這樣的圖書館廣泛使用前向聲明。看看它，看看你是否喜歡它的味道。

來源

2011-03-01 17:51:43 j4x

我認爲這會令人困惑。當你編寫C++時，你應該避免使它看起來像Java或C＃（或C :-)。我真的很想知道你爲什麼這麼做。

提供一個包含所有文件實際上也沒有什麼幫助，因爲用戶可以很容易地自己創建一個，實際使用庫的部分。然後可以添加到預編譯頭中，如果使用了。

來源

2011-03-01 18:38:19

包含所有內容，用「使用」分開

回答

相關問題