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

2019-11-17 05:14:20

字體：大中小

來源：轉載

供稿：網友

介紹

　　我們完成了一次C++對象模型深度探索。雖然只是說是淺嘗即止，但也有不少收獲。　　雷神使勁的搓搓手（心情激動，好象按F5之前的感覺，同時北京的天氣太冷了，手腳冰涼），翻開了《深度探索C++對象模型》最后一章。On the Cusp of the Object Model.。首先瀏覽了一遍本章，噢，這章為我們解釋了三個C++的特性，模板類，異常，運行時類型識別，同時還順便說了一些以前很模糊的概念，例如引用和指針的區別。好了讓我們開始最后的沖刺?！　emplate最初是為了對lists和Arrays提供支持，但是現在它已經成為了Standard Template Library,STL的基礎了。它也被用于屬性混合或者互斥機制中。（雷神隱隱感到C#的裝箱和拆箱的底層也是由Template實現，當然肯定C#底層用了大量的Template，但是BOX是我的第一反應J）。我們先來聲明一個Template class見下：
template ＜class Type＞
class Point
{
public:
enum Status{unallocated,normalized};
Point(Type x=0.0, Type y=0.0, Type z=0.0);
~Point();void* Operator new(size_t);
void operator delete(void*,size_t);
//……
PRivate:
static Point＜Type＞ *freeList;
static int chunkSize;
Type _x, _y,_z;
};　　當編譯看到這個Template class聲明時，沒有任何反應。這個很好理解因為編譯器還不知道到底要為Template class的對象分配多少內存大小，因為它是Template class。所以編譯器什么都不做。它的成員也不能直接調用，我們只能通過Template class的某個實體對象來存取操作，向下面這樣。

　　Point＜float＞::Status s
　　什么時候編譯器會真正的實現出一個實體對象呢？我們來看三種情況：

　　1、 const Point＜float＞ origin;
　　這個是禿子頭上的虱子，明擺著的，肯定會產生一個實體對象?！　?、 const Point＜float＞ &ref=0;
　　它會被內部擴展為：
　　Point＜float＞ temporary(float(0));//在著里已經產生一個臨時的對象。
　　const Point＜float＞ &ref=temporary;
　　因此這樣也可以產生，只不過是編譯器暗中實現的。　　3、 Point＜float＞ *ptr=0;
　　這個也簡單，肯定是沒有實體對象產生。因為指向類對象的指針并不是一個對象，這行代碼并不能告訴編譯器于該類有關的信息，如數據成員，或者對象的數據布局。因此這樣寫編譯器也不會干活?！　⌒碌膯栴}來了。一個類有很多的成員函數，并且你很可能不會都使用到它們，因此編譯器應該在使用這個成員函數時，才將它實體化。這樣才能保證效率。目前的編譯器提供了兩個策略，一個是編譯時期策略，一個是鏈接時期策略。

　　具體的做法如下：

　　1、包含template program text file，就好象是頭文件，Borland遵循這一策略。我們要求Point.h中發現的函數聲明的template program text file放置在Point.h或Point.cpp中。這樣編譯器可以找出函數的定義。
　　2、把一個類的所有成員函數都產生出來。Borland遵循這一策略（這樣其不喪失了些效率？它通過#pragmas來壓制特定實體）?；蛘叻抡骀溄硬僮鳎瑱z測哪個函數真正需要，然后產生實體。這樣做可以只具體實現程序中用到的成員函數。
　　3、后為了阻止成員的定義在對個對象文件中都被具現，做法是產生多個實體，然后通過鏈接器只留下一個實體。或者由使用者引導仿真鏈接階段，決定哪些實體是需要的?！　线€介紹了Edison的編譯器機制，很符合template的原始涵義，主要過程如下：

　　1、一個程序的代碼被編譯，不會產生template的具現體，但相關信息已經產生于對象文件。
　　2、當對象文件被鏈接時，會有一個prelinker程序執行，它會檢查對象文件，尋找template實體的相互參考和對應的定義。
　　3、對于每一個參考到template實體，但實體未被定義時，prelinker把它視為與另一個文件同類。Prelinker會生成一個.ii文件用來記錄檢測結果。
　　4、prelinker重新執行編譯器，重新編譯每一個被改變了的.ii文件，不斷重復此操作，直到所有的必要實現都已完成。
　　5、所有的對象文件被鏈接成一個可執行文件?！　∷钥梢钥闯瞿壳暗木幾g器在template實體產生時會增加大量的編譯時間?！　‘惓Ｌ幚硐鄬唵危蠹以谄綍r的寫代碼時肯定會大量的用到。加入異常可以提高程序的健壯，并且可以在調式代碼時獲得幫助，例如你可以將你需要的信息throw出來。站在編譯器的角度，主要工作是找到catch子句，處理被拋出的異常情況。完成這一工作，編譯器需要利用RTTI機制來識別和查詢異常對象的類型，還要有一個機制治理被拋出的異常對象。一般來說異常處理需要與編譯器所產生的數據結構和執行期的一個異常庫緊密合作。這樣做勢必也會影響程序的大小和執行速度。當我們編譯代碼時，編譯器（VC）會讓我們來進行選擇，是要速度還是要大小，其實取決與在編譯時期所建立的支持數據結構。好了這個問題就不多說了。　　在面向對象的編程中多態的數據類型被大量的應用，同時還有很多內建的或者非多態的數據類型，多態肯定會需要一些額外的負擔，例如：因為需要大量的downcast操作，所以需要一個空間存儲類型信息，通常是一個指向類型信息節點的指針。如何保證這兩種不同的類型都能獲得最合適的空間和效率呢。這也是編譯器需要做的事情。(RTTI,Runtime Type Identification)do執行期類型識別便是解決這一問題的方法。
　　C++的RTTI機制提供一個安全的downcast設備，只對多態的類型有效。如何一眼便能看出這個類是否是一個獨立的ADT或者是一個支持多態的可繼續的子類呢？計算機沒有照妖鏡，也沒有火眼金睛。只能由我們為他提供一個策略，或者說是判定的標準。這個問題在前面已經研究過了，一個具備多態性質的class，肯定含有繼續或者直接聲明的一個或者多個虛函數。編譯器知道了這個類是否是多態后會將，與這個類相關的RTTI對象地址放進這個對象的虛函數表中。這樣一來一個對象只需要多一個指針而已。我們的額外負擔被降到了最低?！　『昧?，就到這里吧。我們完成了一次C++對象模型深度探索。雖然只是說是淺嘗即止，但也有不少收獲。我會再寫一個完結篇，寫寫感受。以呼應開頭。有始有終嗎。假如有愛好可以看看。

上一篇：C++常類型(const)

下一篇：深度探索C++對象模型（2）