最后一章~~拖了幾天，得趕緊記下了~~
名字： On the cusp of the object model
7.1 Template
Template用的很少，這節(jié)中的有些東西比較晦澀，挑一些能理解的記下吧。剩下的等用的多了再回頭來(lái)看。
Template的具現(xiàn)行為 template instantiation
Template <calss T>class Point{
public: enum Status{unallocated,normalized};Point(T x=0.0,T y=0.0);
~Point() ; void * operator new(size_t);private:static Point<T> *freelist
static int chunksize; T _x,_y;
};
編譯器看到這樣的聲明，會(huì)有什么動(dòng)作？？
沒(méi)有。static data 不可用 enum 不可用 ，enum雖然類型固定，但他只能和template point class 的某個(gè)實(shí)體來(lái)存取或操作。我們可以 point<float>::Status s;
但是不能 point::status s; 因此我們可能想把enum抽離到一個(gè)非模板類以避免多重拷貝。同樣道理，freelist 和chunksize對(duì)于程序而言也不可用。必須明確指定point<float>::freelist.也就是說(shuō)靜態(tài)數(shù)據(jù)成員是和特定類型的類綁定的而不是泛型的模板類。但是如果定義一個(gè)指針不一定會(huì)具現(xiàn)出相應(yīng)的類，因?yàn)橐粋€(gè)指針，并不一定指向一個(gè)class object。編譯器不需要知道該class 相應(yīng)的任何member 或者數(shù)據(jù)或者
內(nèi)存布局，所以沒(méi)有必要具現(xiàn)。但是如果是定義并初始化一個(gè)引用就真的會(huì)具現(xiàn)出一個(gè)實(shí)體，因?yàn)椴淮嬖诳找谩?/font>
成員函數(shù)并不應(yīng)該被實(shí)體化，只有當(dāng)他被調(diào)用的時(shí)候才需要被具現(xiàn)出來(lái)。
template<class T>
class mumble{
public: Muble(T t=1024):tt(t){ if(tt!=t)throw ex; }
private: T tt;
};
上面的模板中出現(xiàn)錯(cuò)誤有，t=1024 不一定成功，!= 不一定定義
這兩個(gè)錯(cuò)誤只有到具現(xiàn)操作結(jié)合具體類型才能確定出來(lái)
編譯器面對(duì)一個(gè)template聲明，在他被一組實(shí)際參數(shù)具現(xiàn)之前，只能實(shí)行以有限地錯(cuò)誤檢查，只有特定實(shí)體定義之后，才會(huì)發(fā)現(xiàn)一些與語(yǔ)法無(wú)關(guān)的但是十分明顯的錯(cuò)誤，這是技術(shù)上的一大問(wèn)題。
Template 的名稱決議方式
.h文件定義
void out(int x){
cout<<"out_by_class_define_scrope"<<endl;
}
template <class type>
class A{
public:
void test1(){
out(m1);
}
void test2(){
out(m2);
}
private:
int m1;
type m2;
};
.cpp文件定義
void out(double x){
cout<<"out_by_class_instantiation_scrope"<<endl;
}
int main(）
{
A<double> a;
a.test1();
a.test2();
}
按照書(shū)中的說(shuō)法，如果一個(gè)函數(shù)，參數(shù)類型和type無(wú)關(guān)的話，應(yīng)該取他的scope of template declaration中定義的函數(shù)，而反之取在他的instantiation中的那個(gè)。事實(shí)上在測(cè)試中發(fā)現(xiàn)
MSVC 中 ，函數(shù)定義的決議是依照類型的，如果有合適的函數(shù)比如type是double，此時(shí)如果定義處或者具現(xiàn)處有double型的函數(shù)定義，那么函數(shù)就會(huì)決議為那一個(gè)定義的~~~
MEMber function的具現(xiàn)行為：
編譯器如何確保只有一個(gè)vtable產(chǎn)生？ 一種方法是 每一個(gè)virtual func地址都放在vtable中，如果取得函數(shù)地址，則表示virtual func 的定義必然出現(xiàn)在程序的某個(gè)地點(diǎn)，否則程序無(wú)法連接成功。此外該函數(shù)只能有一個(gè)實(shí)體，否則也是連接不成功。那么，就把vtable放在定義了該class的第一個(gè)non-inline，nonpure virtual function的文件中吧。。（not so clear）
在實(shí)現(xiàn)層面上，template 似乎拒絕全面自動(dòng)化，以手動(dòng)方式在個(gè)別的object module中完成預(yù)先的具現(xiàn)工作是一種有效率的方法。
7.2異常處理
為了維持執(zhí)行速度，編譯器可以在編譯時(shí)期建立起用于支持的數(shù)據(jù)結(jié)構(gòu)
為了維持程序大小，編譯器可以在執(zhí)行期建立數(shù)據(jù)結(jié)構(gòu)
c++ eH 主要由三個(gè)部分構(gòu)成：
throw語(yǔ)句
catch語(yǔ)句
try語(yǔ)句，這些語(yǔ)句可能觸發(fā)catch子句起作用
一個(gè)exception 被拋出時(shí)候，控制權(quán)會(huì)從函數(shù)調(diào)用釋放出來(lái)，并尋找一個(gè)吻合的catch，如果沒(méi)有那么默認(rèn)的處理例程terminate()會(huì)被調(diào)用，控制權(quán)放棄后，堆棧中的每一個(gè)函數(shù)調(diào)用也被推離。每一個(gè)函數(shù)被推離堆棧的時(shí)候，函數(shù)的local class object 的dtor也會(huì)被調(diào)用。
在程序不同段里，由于聲明不同的變量，一個(gè)區(qū)域可能因?yàn)樵趨^(qū)域內(nèi)發(fā)生exception的處理方式不同分成多個(gè)區(qū)段。
在程序員層面，eh也改變了函數(shù)在資源上的管理。例如下面函數(shù)中更含有對(duì)一塊共享內(nèi)存的locking和unlocking操作 ：
void mumble(void * arena){
Point *p= new point ;
smlock(arena) ;
//…..如果此時(shí)一個(gè)exception發(fā)生，問(wèn)題就產(chǎn)生了
sumunlock(arena);
delete p;
}
從語(yǔ)義上講，我們?cè)诤瘮?shù)退出堆棧之前，需要unlock共享內(nèi)存并delete p，我們需要這樣做：
try{smlock(arena)} catch(…){
smunlock(arena); delete p; throw;
}
new不需要放在try段里，因?yàn)椋绻鹡ew發(fā)生了exception，heap中的內(nèi)存并沒(méi)有分配，point的ctor沒(méi)有調(diào)用，如果在ctor中exception，那么piont的任何構(gòu)造好的合成物也會(huì)自動(dòng)解構(gòu)掉，heap也會(huì)自動(dòng)釋放掉。
處理這種資源管理問(wèn)題，建議： 把資源需求封裝在一個(gè)class object 體內(nèi)，并由dtor釋放資源.
auto_ptr<point> ph (new point); smlock sm(arena);//如果此時(shí)exception 沒(méi)有問(wèn)題
// 不需要明確的unlock 和delete
// local dtor 會(huì)在這里被調(diào)用 sm.SMlock::~smlock(); ph.auto_ptr<point>::~auto_ptr<point>
Exception handling 的支持：
1.檢驗(yàn)發(fā)生throw操作的函數(shù)
2.決定throw是否發(fā)生在try區(qū)段里
3.如果是編譯器必須把exception type 拿來(lái)和catch比較
4.吻合的話控制權(quán)交給catch
5.如果throw不發(fā)生在try段或者沒(méi)有吻合的，系統(tǒng)會(huì)摧毀所有active local object b從堆棧把當(dāng)前函數(shù)unwind掉 ，跳出到程序堆棧的下一個(gè)函數(shù)去，然后重復(fù)上述步驟
當(dāng)一個(gè)實(shí)際對(duì)象在程序執(zhí)行時(shí)被拋出，exception object會(huì)被產(chǎn)生出來(lái)并通常放在相同形式的exception 數(shù)據(jù)堆棧中。
catch(expoint p){
//do sth
throw;
}
以及一個(gè)exception object 類型為 exVertex 派生自 expoint ，這兩種類型都吻合，catch會(huì)怎么做
以exception object作為初值，像函數(shù)參數(shù)一樣會(huì)有一個(gè)local copy，如果p是一個(gè)object而不是一個(gè)reference ，內(nèi)容被拷貝的時(shí)候，這個(gè)object的非expoint部分會(huì)被切掉，如果有vptr 會(huì)被設(shè)定為expoint的vptr，如果被再次丟出呢？丟出p需要再產(chǎn)生另外一個(gè)exception 臨時(shí)對(duì)象，丟出原來(lái)的異常 ，之前的修改統(tǒng)統(tǒng)作廢。但是如果 catch(expoint& p);怎么樣呢。 任何對(duì)這個(gè)object的改變都會(huì)繁殖到之后的catch語(yǔ)句總。
c++ 編譯器為了支持EH付出的代價(jià)最大，某種程度是因?yàn)閳?zhí)行期的天性以及對(duì)底層硬件的依賴。
7.3 RTTI
RTTI是Except handling的一個(gè)附屬產(chǎn)品，因?yàn)槲覀冃枰峁┠撤N查詢exception objects的方法，用來(lái)得到exception的實(shí)際類型。
在向下轉(zhuǎn)型問(wèn)題上，如果要保證其安全性，那么必須在執(zhí)行期對(duì)指針有所查詢，看看它到底指向什么類型的對(duì)象。那么我們需要額外的空間存儲(chǔ)類型信息，通常是一個(gè)指針，指某個(gè)類型信息節(jié)點(diǎn)。
需要額外的時(shí)間以決定執(zhí)行期的類型。
沖突發(fā)生在：
1.程序員大量的使用了多臺(tái)，并需要大量的downcast操作
2.程序員使用內(nèi)建的數(shù)據(jù)類型和非多態(tài)，他不需要額外負(fù)擔(dān)帶來(lái)的便利
那么如何了解程序員的需要呢？？ 策略是一個(gè)具有多態(tài)性性質(zhì)的class，也就是具有內(nèi)涵繼承或者聲明 virtual func的類需要rtti支持。
這樣所有多態(tài)類維護(hù)一個(gè)vptr。額外負(fù)擔(dān)降低到：每一個(gè)class object多花費(fèi)一個(gè)指針，指針只被設(shè)定一次，而且是編譯器靜態(tài)設(shè)定。
down_cast
if(pfct pf = dynamic_cast< pfct >(pt))….
((type_info*)(pt->vptr[0]))->type_descripter;
Reference --------Pointer
dynamic_cast執(zhí)行在ptr上 失敗返回0，如果實(shí)行在ref上。由于ref不能被賦予null，也就是沒(méi)有空引用。如果我們把一個(gè)ref設(shè)為0會(huì)引發(fā)臨時(shí)對(duì)象產(chǎn)生，然后用0初始化它，使ref成為這個(gè)臨時(shí)對(duì)象的別名。因此此時(shí)失敗了會(huì)產(chǎn)生一個(gè)bad_cast exception。
typeid的參數(shù)可以使引用，對(duì)象或者是類型
事實(shí)上，type_info 也適用內(nèi)建類型，這對(duì)于eh機(jī)制有必要
例如 int ex_errno; throw ex_errno;
其中int類型 int *ptr; if(typeid(ptr) == typeid(int*));
----------------------全書(shū)筆記到此結(jié)束 --------------------------------s