在C++中get/set方法變量的方法聲明的編程風格？

Question

如果您在.h文件中聲明該類的getters/setters，然後在.cpp中定義它們或者在.h文件中執行這兩個操作。你喜歡哪種風格，爲什麼？我個人喜歡後者，其中所有的都在.h中，而且除了.cpp中的setter/getters之外，只有那些與之相關的邏輯的方法。

Answer 1

對我來說，這取決於誰將使用.h文件。如果它是一個很大程度上在模塊內部的文件，那麼我傾向於將小方法放在標題中。如果它是一個更外部的頭文件，它提供了一個更加固定的API，那麼我將把所有的東西放在.cpp文件中。在這種情況下，我經常使用PIMPL Idiom作爲完整的編譯防火牆。

權衡我把他們的頭看到的是：

• 少打字
• 更容易內聯編譯器
（雖然編譯器有時會做多個翻譯單位之間的內聯反正現在。）
• 更多的編譯依賴

Answer 2

我要說的是，頭文件應約接口，而不是實現。我會把它們放在.cpp中。

Answer 3

我幾乎總是跟隨宣佈他們的頭，並在源定義的劃分。每當我不這樣做，我最終都不得不回過頭去做任何事情。

Answer 4

我把放在頭的所有單套只要他們並不需要太多的附加頭包括（因爲其他類的調用方法）。 我也不要試圖把所有的代碼在同一行，所以我可以把大部分的方法在頭:-)

但無論如何喬希提到一個很好的理由把他們在.cpp：如果標題是供外用。

Answer 5

我更願意把它們放到.cpp文件，爲快速編譯/鏈接倍的緣故。即使是很小的單行程序（空虛擬析構函數）也會浪費你的編譯時間，如果它們被實例化了很多。在一個項目中，我可以通過將所有虛擬析構函數移動到.cpp文件中來縮短編譯時間。

從那時起，我賣了這一點，我只會把它們放到頭，如果再探查告訴我，我可以從內聯獲利。唯一的缺點是你需要更多的輸入，但是如果你在編寫頭文件時創建.cpp文件，你通常可以複製&粘貼聲明並將它們填充到.cpp文件中，所以沒有那麼糟糕。更糟糕的是，如果你後來發現你想將東西移動到.cpp文件中。

一個不錯的副作用是，當您的頭文件中只有文檔和聲明時，閱讀內容更簡單，尤其是在新開發人員加入項目時。

Answer 6

我使用下一個規則：聲明的頭，實現的代碼文件。這成爲實際，當你的頭是項目之外使用 - 比更輕量級的標題是，那麼它在使用

Answer 7

我寧願保持.h文件儘可能乾淨的更多的舒適。因此，像get/set一樣簡單的小函數經常用於將單獨的文件作爲內聯函數定義，然後將該文件（我將擴展名爲.inl的位置）包含到該文件中。h頭文件：

// foo.h 

class foo 
{ 
public: 
    int bar() const; 

private: 
    int m_bar; 
}; 

#include "foo.inl" 

// foo.inl 

inline 
int foo::bar() const 
{ 
    return m_bar; 
} 

我認爲這提供了最好的兩個世界，同時隱藏最頭中的執行，並且仍然保持內聯簡單的代碼的優勢（作爲一個經驗法則我最多保留3條語句）。

Answer 8

對我來說這取決於我在做什麼與代碼。對於我要維護和持續很長時間的代碼，我把在.cc文件，原因如下的一切：

• .h文件可以保持稀疏的文檔，誰想要尋找函數和方法的人定義。
• 我的團隊編碼準則聲明，我們將所有內容放在.cpp文件中，並且喜歡遵循這些規則，即使函數定義只需要一行。這消除了猜猜遊戲的真實位置，因爲你知道應該檢查哪個文件。
• 如果您正在頻繁地重新編譯一個大項目，那麼將函數定義保存在.cpp文件中會比在頭文件中保存函數定義節省一些時間。這一點最近對我們來說很重要，因爲我們最近瀏覽了代碼並添加了許多運行時斷言語句來驗證我們類的輸入數據，並且這需要對getter和setter進行很多修改。如果這些方法聲明已經存在於.cpp文件中，這會變成我們的乾淨的重新編譯，這可能會花費我的筆記本電腦大約30分鐘。

這並不是說我不會隨着規則偶爾玩弄快速和骯髒的事物，並在執行某些事情時將事情放在.h文件中，但對於代碼，我認真對待所有代碼不管長度）在.cpp文件中。對於大項目（有些）規則是有原因的，遵循它們可以是一種美德。說到這一點，我只想到另一個Perl腳本，我可以一起查找違反編碼準則的行爲。很受歡迎。 :)