深度探索C++對象模型（2）

2019-11-17 05:14:20

字體：大中小

來源：轉載

供稿：網友

　　筆記貼出后，有朋友便給我提出了一個很好的建議，原文如下：

　　史列因：我剛看了你寫的“深度探索C++對象模型(1)”，感覺很不錯。不過我有一個建議：你說“誰知第一章便如此的難以消化，已經反復讀了3遍，還是有些夾生”是很自然的。第一章是一個總覽，假如你能全看懂，后面的就沒什么看的必要了。第一章的內容后面都有具體介紹，開始只要有個大概印象就可以了。這本書中很多內容都是前后重復的。我建議你先不管看懂看不懂，只管向后看，之后再從頭看幾遍，那樣效果好得多。

　　我想史列因說的應該是一種非常好的閱讀方式，類似《深度探索C++對象模型》這樣的技術書籍，需要的是理解，和學習英文不同，不能靠死記硬背，假如出現理解不了的情況，那你不妨將書放下，打一盤紅警（俺驕傲的說，我是高手）。或者跳過去也是一個不錯的方法。好了，我們還是繼續研究C++的對象模型吧。　　簡單的對象模型

　　看書上的例子（注釋是表示solt的索引）
Class Point
{
public:
Point(float xval); //1
virtual ~Point(); //2float x() const; //3
static int PointCount(); //4
PRotected:
virtual ostream& print(ostream &os) const; //5
float _x; //6
static int _point_count; //7
}　　每一個Object是一系列的Slots,每一個Slots指向一個members。　　表格驅動對象模型　　當構造對象時便會有一個類似指針數組的東西存放著類數據成員在內存中位置的指針，還有指向成員函數的指針。為了對一個類產生的所有對象實體有一個標準的表達，所以對象模型采用了表格，把所有的數據成員放在數據成員表中，把所有的成員函數的地址放在了成員函數表中，而類對象本身有指向這兩個表的指針。　　為了便于理解，雷神來舉個不恰當的例子說明一下，注重是不很恰當的例子我們把寫字樓看成一個類，寫字樓中的人看成是類的數據成員，而每一個租用寫字樓的公司看成類的成員函數。我們來看一個實體，我們叫它雷神大廈。雷神大廈的物業治理部門需要登記每個出入寫字樓的人，以便發通行證，并且需要登記每個公司的房間號，并制作了一個牌子在大廳的墻上。實際上這便是類的對象構造過程。你可以通過大廳墻上的公司列表找到任何一家在雷神大廈租房的公司，也可以通過物業提供的花名冊找到任何一個出入雷神大廈的人。　　真是一個考驗大家想象力的例子。（假如你有更好例子的別忘了和雷神交流一下）。　　C++的對象模型

　　C++對象模型是從簡單對象模型派生得來，并對內存空間和存取時間做了優化。它引入了虛函數表（virtual table）的方案。每個類產生一堆指向虛函數的指針，放在表格中。每個類的對象被添加了一個指針（vptr），指向相關的虛函數表（virtual table）。而這個指針是由每一個類的constrUCtor、destructor和copy assignment運算符自動完成。　　我們還用上面的雷神大廈舉例，物業治理為了提高效率，對長期穩定的公司和人員不再登記，指對不穩定或不能確定的公司進行登記，以便于治理。

　　再次考驗大家的想象力。　　得出結論，C++對象模型和雙表格對象模型相比，提高了空間和存儲時間的效率，卻失去了彈性。　　試想一下，沒有整個雷神大廈人員和公司的名錄，假如他們發生變化，則需要物業治理部門做很多工作。重新確定長期穩定的公司和人員是那些。對應應用程序則需要重新編譯。（這次更離譜，但為了保持連貫，大家請進行理解性的思考，不要局限字面的意思）　　這篇筆記是分成多次一點點寫的，甚至天天抽出一個小時都不能保證（沒辦法最近實在忙），因此可能會有不連貫，假如你讀起來很不爽認為雷神的思維短路了，那屬于正常。不過雷神還是再上傳之前努力的將思路進行了一下整理。希望能把這些支言片語串起來。　　最后說一句閱讀《深入C++對象模型》一書感覺沒有什么可以被成為重點的東西，感覺每一個字都不應該放過，全是重點。經過反復閱讀，雷神好象有些開竅，繼續努力呀，我和大家都是。

上一篇：深度探索C++對象模型（10）

下一篇：gcc_egcs使用