C++ 下啥時候用struct, 啥時候用class

struct 由c語言引入。在c語言中，是定義結構化數據的標準選擇。

c++ 同時支持struct 和 class. 緣由之一是c++ 是 c 的超集，涵蓋c 已支持的語言要素，將更好的支持向下兼容(原來可以工做的c 源程序移植到c++，能夠支付極少甚至0代價)

 

實際上，c++ 的class已經對struct 進行了徹底的覆蓋，便是說，原來用struct 實現的結構體，徹底能夠用class 代替。

那麼問題出來了，一個新項目, 何時應該使用struct, 一樣的東西，用struct實現或者用class實現，性能上有沒有區別。

 

struct 和 class 實際在C++ 中沒有什麼區別。

struct 仍然能夠繼承自另外一個struct (不多看到有人這麼幹)。

struct 默認的字段類型是public, 默認的繼承方式也是public, 而class 的默認字段類型是private, 默認繼承方式也是private。

未見任何文檔有描述說struct 比 class 更快。我的感受既然struct 和 class 在實現上能夠互換，也就是說要支持相同的語言級基礎設施和複雜度，那麼就不該該存在用哪一個更快的問題(同等級別對象, 你不能拿一個有4個字段的Rect 結構體 和一個帶Hashtable 的ResManager相比)

 

因爲struct 和 class 的可替換性，何時用struct 和何時用class的選擇就至關主觀了。一般你們的直覺是一致的: struct 應該應用於POD(Plain old data)類型的對象. 用一個詞來描述，他們更像是記錄, 一個簡單的集合，裏面有幾個字段， 例如 struct Color, struct Rect, struct Point 等都是咱們常見的結構。

而class 實際上更適合用於抽象主動的對象, 他們一般能夠有複雜的繼承關係(我的認爲太複雜是一種做死的行爲，稍後解釋)。 或許有更多的方法和邏輯。對於class來說，內部數據除了理解爲記錄, 更有一部分是「狀態」。

另一個struct 的好處是:

它能夠很方便的序列化和反序列話，好比，直接拿到一個struct 的指針。 sizeof取得大小，直接把對象存儲到文件或寫入網絡。固然基於某些緣由。我也不建議這麼作。

 

順口說一句：我其實更傾向於基於對象而反對Pure面向對象。

教課書上，爲了教會人使用C++, 一般會這麼舉例：

好，你如今定義一個「人」，那麼他的繼承樹應該是這樣的：

有莫有，有莫有這樣的。

人還有相似 說話，吃飯，騙其餘人感情和身體 這些方法。

猴子就要簡單些，只會叫喚，可是因爲他們都繼承自哺乳動物，因此他們都有繼承自哺乳動物的方法 餵奶。至於植物系的，固然就沒有那麼高級了，可是他和哺乳動物同樣，又從LivingThing 那裏繼承了一些東西，好比生長和死亡。固然我認可那個植物人是開玩笑的。

還有一些是拿交通工具舉例的。。看起來多麼優雅，代碼重用性超高。

 

對於這種爲了面向對象而面向對象的思惟方式，我只想說看到這樣的代碼，能夠直接拖出去斃了。緣由是，稍微複雜點的項目，沒人會這麼幹。由於繼承樹的深度在以指數的方式影響複雜度。有天你會發現，想實現一個SuperMan, 根本無從下手，想改變一個基類方法，不知道他最終會影響哪些類。

 

我贊成muduo的做者那個誰的觀點：

在你要對一個代碼進行修改(多是Fix bug, 也多是添加一個新的功能), 首先要作的事情，絕對不是直接擼袖子開始幹代碼。首先是要想出要怎麼改。爲了要想出一個方案，你首先要了解當前的代碼，把代碼理解了，就如同內存裝載數據同樣。優雅的代碼，你只須要了解不多的相關代碼（這也是提倡解耦的緣由)。因此若是是上圖所示的代碼。。我想問問你的腦存今年有沒有升過級。

 

我本身比較接受Service 和 Data分開的原則，模塊化比面向對象更重要，另外在基礎框架穩固的前提下。基於組件的設計原則也是極其爽的，特別是遊戲開發。Unity3d的引擎就是基於組件的。啥都是組件。

嗯，固然這是另外一個議題。我好像嚴重跑題了。

 

因而今年是2015年了。我上一次，最後一次更新博客是,擦 2008年離如今有7年了。

如今我回來了。

有些時候腦殼裏面好多似是而非的東西，不如認真去調查，順手再寫篇log做爲記錄。

也歡迎任何人怒罵嘲諷。