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