大家好，小弟玩了C 一段日子，發現C 教學書及C 的範例，很喜歡把類別或函式原型宣告在標頭檔中，然後用一個cpp檔去實作那類別及函式。 我只知道其中一個原因是因為源代碼不便向用戶公布，故用標頭檔作為接口給用戶調用，但除了這個我就找不到其他好處了，只是覺得非常麻煩，現在我寫C 程式中只會有一個cpp檔，其他類別宣告及實作我都是直接放入標頭檔中，我覺得這樣反而很方便及易維護。 請問我這樣做是否正確? 謝謝大家。

當您的程式只需要單一個 unit 即可完成時，這樣確實是最簡便的方式， 但如果您的程式有多個 unit 一同完成，則 unit 間相互叫用，有 .h 檔 會比較方便，因為需要的 unit 就 include 有用到的 unit.h 即可。    所有元件寫在一個 .cpp 檔，如果您的 .cpp 內放了各式不同的元件， 日後如果寫了相關的軟體，則需要用 copy/paste 的方式來處理， 但如果您已把可獨立的元件寫成 .h/.cpp 則不同的專案用到時， 只需 include 它，而不必再 copy/paste ，如此可以簡少 copy/paste 多或漏的問題，而且相同的 unit 多個專案使用，也可以由多個專案 測試元件的穩定性，如果寫程式都是全部一個 .cpp 那您的程式想必 不太模組化。    個人建議提供參考。對於應付學校作業，一個 .cpp 就夠了  < href="http://free.greenworld.com.tw/~dllee/" target="blank">吃軟也吃硬 dllee.ktop.com.tw StatPlus 系統資源監測器 @ KTOP OpenPLC - IEC 61131-3 geOShell XP Like 中文版

------
http://www.ViewMove.com

我不是把所有元件也放入cpp中，我只是把main()函式放入唯一一個cpp中，若有其他class如classA，我就把宣告及實作都放入classA.h中，有classB就放入classB.h中，若主程式要用classA時，就include "classA.h"，若classA我有東西要改時，就直接改classA.h。

如果是這樣，那大部分的人都是這樣寫程式的呀，並沒有什麼問題。 以 BCB 開一個 project 她也是有    project.cpp projectUnit1.cpp projectUnit1.h    而在 project.cpp 有主程式並 include projectUnit1.h 或 useform/useunit  projectUnit1.cpp    吃軟也吃硬 dllee.ktop.com.tw StatPlus 系統資源監測器 @ KTOP OpenPLC - IEC 61131-3 geOShell XP Like 中文版

------
http://www.ViewMove.com

但我見除了主程式的.h、.cpp外，當有新的class要加入時，他們會先建立一個.h檔來寫類別及函式原型，另外再建立一個.cpp來實作那個.h，最後整個程式會有兩個.h及兩個.cpp檔。 而我的做法時每檔有新class加入，我只會為class建立一個.h檔，當中包含了函式原型及實作。而cpp只會有一個，只放入main()。

引言: 但我見除了主程式的.h、.cpp外，當有新的class要加入時，他們會先建立一個.h檔來寫類別及函式原型，另外再建立一個.cpp來實作那個.h，最後整個程式會有兩個.h及兩個.cpp檔。 而我的做法時每檔有新class加入，我只會為class建立一個.h檔，當中包含了函式原型及實作。而cpp只會有一個，只放入main()。

1.有新class加入，何必為class建立一個.h檔呢? 用該.cpp的.h檔就了,方便管理,更懶一點,直接寫在.cpp(main())的前面,連建什麼.h也不用. 2.會多做一個.h,最主要是方便管理,如高中同學放在一起,大學同學放在一起.找起方便,當只有兩三隻小貓,何必再分高中大學呢? 3.再來就是你的程式中有我,我的程式中有你的時候,分開比較好. 發表人 - brook 於 2005/03/08 08:24:38

引言: 但我見除了主程式的.h、.cpp外，當有新的class要加入時，他們會先建立一個.h檔來寫類別及函式原型，另外再建立一個.cpp來實作那個.h，最後整個程式會有兩個.h及兩個.cpp檔。 而我的做法時每檔有新class加入，我只會為class建立一個.h檔，當中包含了函式原型及實作。而cpp只會有一個，只放入main()。

我了解了，您是 .h 檔內包含了元件的所有原始碼。 對於小系統來說，沒有什麼問題，可能多花的時間不多， 但對於一個大系統來說，可能這樣的架構會讓 compile 的時間加長。 例如: A.h B.h C.h M.cpp 在 A,B,C 之間如果完全沒有相互的 include 則沒有影響， 但如果 B,C,M 都 include A, 而當 A 的實作改變時，B,C,M 都要 rebuild。 但如果 A.h A.cpp B.h B.cpp C.h C.cpp M.cpp 則當 A.cpp 改變時，B.cpp,C.cpp,M.cpp 不必 rebuild 只需 compile A.cpp 就可以 link 了。 這在大系統中會更明顯。 當然，這是個人寫作習慣的問題，沒有對錯的問題，C/C 已有幾十年的歷史了，80%(我亂猜的) 以上的人被要求要 . href="http://free.greenworld.com.tw/~dllee/" target="blank">吃軟也吃硬 dllee.ktop.com.tw StatPlus 系統資源監測器 @ KTOP OpenPLC - IEC 61131-3 geOShell XP Like 中文版

引言: 但我見除了主程式的.h、.cpp外，當有新的class要加入時，他們會先建立一個.h檔來寫類別及函式原型，另外再建立一個.cpp來實作那個.h，最後整個程式會有兩個.h及兩個.cpp檔。 而我的做法時每檔有新class加入，我只會為class建立一個.h檔，當中包含了函式原型及實作。而cpp只會有一個，只放入main()。

我和你的看法不同 為什麼要寫幾個CPP及H 那是因為每一個CPP的功能不同，例如有的是做畫面處理，有的是做功能處理 因為你把不同的功能沏成不同的CPP了，所以你會在相對應的CPP中寫H 而因為你把這些不同功能的CPP切開了 如果你有一個新的專案要用到某一個CPP，你只要將指定的CPP及H加入新的專案即可。 如果你都寫再同一個CPP裡，就達不到切割的功能，就像你在同一個CPP中會模組化，主要也是因為程式碼要再利用吧 所以，應該不是因為新的class而去做新的H再建新的CPP 應該是為了吧功能切出來，而去建立一個新的CPP，而在建立它的H及Class

以我來說，除非完全沒有時間了，必需隨便趕一個給人看， 不然，我一定會先寫 .h/.hpp 再寫 .c/.cpp， (.h/.hpp 可以是一個元件或多個相關的元件及相關的 API) 光是寫 .h/.hpp 的時間也許就花了 3 天，而實作 .c/.cpp 只需半天就可以完成。 .h/.hpp 就如果是規劃介面及部分運作的草案，當認為這是可行的方案後， 再去實作 .c/.cpp 可以事半功倍，而且元件及函式之間的關係可以清楚。 先寫 .c/.cpp 則會是想到什麼寫什麼，但到後來要再加功能時，則會有 這裡加看看，那裡加看看，到最後，又都混在一起了。 先寫 .h/.hpp 也有另一個好處，就是在多人分工的狀況，介面先定好， 就可以多人同時開發，或是自己時間有限，交由其他人去實作 .c/.cpp。    這些都是個人寫作習慣，沒有絕對的對錯，只需選擇適合自己的方式即可。 畢竟，客戶在意的是最後的功能是否有完成，你的程式到底是如何寫的， 客戶並不重視，會重視的是你的公司及上司或你的同事，但如果本來整個 系統就都是你自己一個完成的，那就沒有什麼好在意的了。    吃軟也吃硬 dllee.ktop.com.tw StatPlus 系統資源監測器 @ KTOP OpenPLC - IEC 61131-3 geOShell XP Like 中文版 發表人 - dllee 於 2005/03/08 11:54:49

------
http://www.ViewMove.com

您好 其實當程式架構大時候 覺得相同性質或類別的規劃在同一.h and .cpp會有助於debug trace時較易明瞭 但是若真是小程式 個人覺得應該是沒必要做很多個.h .cpp 但是沒絕對的對或錯 只要是結果對較重要吧 純屬個人意見

哦，我明白了，我現在的程式不算得是非常大，但也不少，內部有很多功能需要日後慢慢增加，故開始的架構是非常重要，但我又不想用太多時間，故現在我會把有Interface功能的類別放入.h，需要實作的就另外建多個.cpp來做。 謝謝大家。

A.C 會附帶 A.H 可能是為了簡化編譯器吧， 其他程式語言好像不太須要