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作為記錄。
也歡迎任何人怒罵嘲諷。