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

2019-11-17 05:14:20

字體：大中小

來源：轉載

供稿：網友

介紹

　　我們完成了一次C++對象模型深度探索。雖然只是說是淺嘗即止，但也有不少收獲。　　雷神使勁的搓搓手（心情激動，好象按F5之前的感覺，同時北京的天氣太冷了，手腳冰涼），翻開了《深度探索C++對象模型》最后一章。On the Cusp of the Object Model.。首先瀏覽了一遍本章，噢，這章為我們解釋了三個C++的特性，模板類，異常，運行時類型識別，同時還順便說了一些以前很模糊的概念，例如引用和指針的區(qū)別。好了讓我們開始最后的沖刺。　　Template最初是為了對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;
　　這個是禿子頭上的虱子，明擺著的，肯定會產生一個實體對象。　　2、 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中發(fā)現的函數聲明的template program text file放置在Point.h或Point.cpp中。這樣編譯器可以找出函數的定義。
　　2、把一個類的所有成員函數都產生出來。Borland遵循這一策略（這樣其不喪失了些效率？它通過#pragmas來壓制特定實體）。或者仿真鏈接操作，檢測哪個函數真正需要，然后產生實體。這樣做可以只具體實現程序中用到的成員函數。
　　3、后為了阻止成員的定義在對個對象文件中都被具現，做法是產生多個實體，然后通過鏈接器只留下一個實體。或者由使用者引導仿真鏈接階段，決定哪些實體是需要的。　　書上還介紹了Edison的編譯器機制，很符合template的原始涵義，主要過程如下：

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

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

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