程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> C語言 >> VC >> vc教程 >> 深度探索C++對象模型(2)

深度探索C++對象模型(2)

編輯:vc教程

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

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

簡單的對象模型

看書上的例子(注釋是表示solt的索引)


Class Point
{
public:
Point(float xval); //1
virtual ~Point(); //2

float 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++對象模型》一書感覺沒有什麼可以被成為重點的東西,感覺每一個字都不應該放過,全是重點。經過反復閱讀,雷神好象有些開竅,繼續努力呀,我和大家都是。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved