今天來講講怎么編寫異常安全的代碼。
程序運行過程中，往往需要對一些流程加入異常處理，來提高程序的robust.比如
通過try catch來捕捉異常
try
{
??? pMemory = new char[MAX_BUF_SIZE];
}
catch(std::bad_alloc& e)
{
??? //error handling,er:do something resource free
}
但在程序代碼段中出現(xiàn)大量的try catch,不僅從美觀，效率和程序輸寫上都是不怎么好。
而另外一種對于異常的處理方法是依賴于c++的ctor/dctor的匹配來做的，就是所謂的
RAII,這個很容易讓人聯(lián)想到std::auto_ptr
std::auto_ptr<int> tmp(new int);
通過new分配的對象會在tmp生命結(jié)束后，釋放相關的資源，通過這種方式，就能保證在程序異常，或退出時，已分配的對象能正確自動的釋放擁有的資源，而在對象聲明周期內(nèi)，可以保證資源的有效性。
這種方式就是今天blog要寫的主要內(nèi)容，我們可以看到std::auto_ptr作用范圍很小，只能對從堆上分配的對象進行管理，假如對文件打開句柄實行RAII,你也許會認為再寫個不就是了，但這樣只會造成源代碼里充滿了這些資源管理的類，這導致了一個嚴重的問題，好的結(jié)構(gòu)在繁瑣的流暢前面變的難堪。
那怎么樣對這個進行泛化，從而能對比如從簡單的指針釋放，文件句柄維護，甚至相關的成員函數(shù)。我們來看下loki::socpeguard是怎么實現(xiàn)的：
先看下基本的用法
(1)? FILE* hFileOpen = fopen(....);
(2)? LOKI_ON_BLOCK_EXIT(flose,hFileOpen);
line2會在出LOKI_ON_BLOCK_EXIT域或程序異常結(jié)束時被調(diào)用，下面是對類成員的調(diào)用
void CTestObject::Create
{
??? LOKI_ON_BLOCK_EXIT_OBJ(*this,FressResouce);
??? ...
}
同上面差不多，會在這個函數(shù)結(jié)束后或異常結(jié)束后調(diào)用類成員的FreeResource.在正常流程結(jié)束后，可以通過調(diào)用Dismiss來防止對FreeResouce的調(diào)用，即類似數(shù)據(jù)庫操作的commit操作。下面來分析下LOKI的實現(xiàn)：
從上面可以看到，RAII的是：
1：構(gòu)造函數(shù)對資源的獲取
2：稀構(gòu)函數(shù)對資源的釋放
先來看下LoKi對上面那2個宏的定義
#define LOKI_ON_BLOCK_EXIT????? Loki::ScopeGuard LOKI_ANONYMOUS_VARIABLE(scopeGuard) = Loki::MakeGuard

#define LOKI_ON_BLOCK_EXIT_OBJ? Loki::ScopeGuard LOKI_ANONYMOUS_VARIABLE(scopeGuard) = Loki::MakeObjGuard
上面的Loki::ScopeGuard是一個基類的別名
typedef const ScopeGuardImplBase& ScopeGuard;
而LOKI_ANONYMOUS_VARIABLE(scopeGuard)用來我們產(chǎn)生唯一的名字，有時假如需要調(diào)用Dismiss的話，則需要自己去實現(xiàn)宏定義的內(nèi)容，這樣才能通過對象訪問。Loki::MakeGuard或Loki::MakeObjGuard是用來產(chǎn)生對象的實際類型的，下面是一個
Loki::MakeGuard的例子：
template <typename F, typename P1>
inline ScopeGuardImpl1<F, P1> MakeGuard(F fun, P1 p1)
{
??? return ScopeGuardImpl1<F, P1>::MakeGuard(fun, p1);
}
可以看到ScopeGuardImpl1<F, P1>是要產(chǎn)生的具體類型，MakeGuard通過函數(shù)參數(shù)的數(shù)目來重載的，而MakeGuard此處的作用是要睡死了...-_-'',作用是利用函數(shù)自動推導出參數(shù)的類型，這樣就免去了指定ScopeGuardImpl1的類型的麻煩，而
ScopeGuardImpl1<F, P1>::MakeGuard(fun, p1);
簡單的返回對象的一個臨時變量，并assign給一個上面的一個scopeguard的實例，這里依賴一個C++的特性，臨時變量的聲命周期和通過他初始化的引用類型的聲明周期是一致的。

從上面可以看到Loki定義了一個ScopeGuardImplBase的基礎類。這個類定義了一個基本的方法Dismiss,以及相關的狀態(tài)。下面是loki中這個類的定義
class ScopeGuardImplBase
{
??? ScopeGuardImplBase& operator =(const ScopeGuardImplBase&);
?protected:
??? ~ScopeGuardImplBase()
??? {}
??? ScopeGuardImplBase(const ScopeGuardImplBase& other) throw()
??????? : dismissed_(other.dismissed_)
??? {
??????? other.Dismiss();
??? }
??? template <typename J>
??? static void SafeExecute(J& j) throw()
??? {
??????? if (!j.dismissed_)
?????????? try
?????????? {
????????????? j.Execute();
?????????? }
?????????? catch(...)
?????????? {}
???? }
???????
???? mutable bool dismissed_;
public:
???? ScopeGuardImplBase() throw() : dismissed_(false)
???? {}
???? void Dismiss() const throw()
???? {
???????? dismissed_ = true;
????? }
};
可以看到類里面定義了上面所說的一些屬性，其中SafeExecute用來提供子類同一的資源釋放方法，并調(diào)用子類的方法來具體操作，因為相關的函數(shù)，變量都保存在具體的子類，可以看到這個函數(shù)使用了try catch，這里加這個的目的是，因為資源釋放要在子類的稀構(gòu)里被觸發(fā)，而調(diào)用具體的方法是外面?zhèn)鬟M來的，所以無法保證一定是異常安全的，而假如在稀構(gòu)里面異常的話，會導致程序的行為無法定義。
下面具體來看下一個子類的實現(xiàn)：
template <typename F, typename P1>
class ScopeGuardImpl1 : public ScopeGuardImplBase
{
public:
??? static ScopeGuardImpl1<F, P1> MakeGuard(F fun, P1 p1)
??? {
??????? return ScopeGuardImpl1<F, P1>(fun, p1);
??? }
??? ~ScopeGuardImpl1() throw()
??? {
??????? SafeExecute(*this);
??? }
??? void Execute()
??? {
??????? fun_(p1_);
??? }
protected:
??? ScopeGuardImpl1(F fun, P1 p1) : fun_(fun), p1_(p1)
??? {}
??? F fun_;
??? const P1 p1_;
};
在LoKi里面可以看到很多類似ScopeGuardImpl1的定義，比如ScopeGuardImpl0，
ScopeGuardImpl2，可以發(fā)現(xiàn)最后面的數(shù)字表示具體參數(shù)的數(shù)目。
可以看到上面所說的MakeGuard的定義，以及對基類方法的調(diào)用，可以看到構(gòu)造函數(shù)接收的類型，一個函數(shù)對象，和一些參數(shù)對象，并保存，對于成員函數(shù)的scopeguard,LoKi定義了1些相似的類，主要是增加了對象的引用，還有就是函數(shù)的調(diào)用方式上。
上面可以看到參數(shù)是通過值的方式來保存的而不是通過引用。而且是const屬性的，下面是相關的分析。
1：通過傳值的方式，從而避免了異常拋出時，可能引用的對象被稀構(gòu)
2：加const屬性，從而保證了在func需要參數(shù)是reference時而保存的參數(shù)確是非const時產(chǎn)生相應的編譯錯誤，因為對reference傳人const non-reference形式是錯誤的。
而對于1的方式，存在的一種問題是假如操作的fun需要傳入引用，那傳進去的值就無法在釋放的函數(shù)中被改變，而2是對這種的一種類似契約似的編程，Loki 提供的方法是通過一個中間對象來保存操作參數(shù)的引用，并賦予這個對象自動轉(zhuǎn)換功能。下面是這個類的定義：
template <class T>
class RefToValue
{??
public:
??? RefToValue(T& ref) : ref_(ref)
??? {}
??? RefToValue(const RefToValue& rhs) : ref_(rhs.ref_)
??? {}
??? operator T& () const
??? {
??????? return ref_;
??? }
private:
??? // Disable - not implemented
??? RefToValue();
??? RefToValue& operator=(const RefToValue&);
???????
??? T& ref_;
};
可以很清楚的看到類的實現(xiàn)，下面是一個工具類
template <class T>
inline RefToValue<T> ByRef(T& t)
{
???? return RefToValue<T>(t);
}
下面給個具體的例子，假如
template<typename _Ty>
void SAFEDELETE(_Ty*& ptr)
{
?? if (NULL != ptr)
????? delete ptr;
?? ptr = NULL;
}

char* ptr = new char;
?
{
??? LOKI_ON_BLOCK_EXIT(SAFEDELETE<char>,Loki::ByRef(ptr));
}
?
if (NULL == ptr)
? std::cout << "NULL" << std::endl;
基本上就這么多了，sleep去了
??????????????????????????????????????????????????? alex_yuu

???????????????????????????????time - task

圖中箭頭指向的方向表示緊迫度的添加,那么下面是關于1,2,3,4的定義:

一:任務比較重要,但相應的時間也很緊

二:任務是長期任務,但比較重要

三:不那么重要的任務,時間也很多

四:不需要多長時間的非重要任務

現(xiàn)在分析下上面的這些:
對于一:往往這個時候處于時間的dead line狀態(tài),而此時往往是我們都不想要的,熟話說事情是急不來的,這個時候往往會導致質(zhì)量的下降.

對于二:我們有充足的時間來做重要的任務,這正是我們想要的,但,怎么做才能使其不會過渡到區(qū)間一呢,轉(zhuǎn)為區(qū)間1往往會由于人的惰性產(chǎn)生的,關鍵是要提前做事.安排好時間.

對于三:往往是一些可以輔助我們成長的事情,這些東西對我們有益處,這對全面的發(fā)展起到了很好的作用,-_-''就象我學吉他..

對于四:是些時間緊,但不重要的任務,比如要幫助人去google一些資料.

從上面可以看到,區(qū)間一實際上是最差的,但為了做好區(qū)間2,我們必須要盡量減少區(qū)間4的份量,而對于全面的發(fā)展,我們也要安排時間到區(qū)間3.這也是很重要的.

前幾天一個朋友給我看了1段代碼：
any temp; //any is a class
temp = 1;
temp = "a";
temp = x; //x is a abstract class
看到這段代碼著實下了1跳.初期的感覺象void*指針那樣，又象variant變量。但感覺還是比較新穎的，-_-''也許我是菜鳥的原因，在腦袋轉(zhuǎn)了一下后，我實現(xiàn)了自己的一個類，用來接受任何參數(shù)，起初我認為any應該是個typedef,而接收的類型也是前面知道的(-_-''又沒弄清需求就去實現(xiàn)了)，所以實現(xiàn)一個接收任何參數(shù)的類需要個typelist,和對每種類型的泛化，下面是class的定義：

template<typename _typelist>
class?any
{
public:
?typedef typename Loki::TL::TypeAtNonStrict<_typelist,0>::Result?param1;
?typedef typename Loki::TL::TypeAtNonStrict<_typelist,1>::Result?param2;
?typedef typename Loki::TL::TypeAtNonStrict<_typelist,2>::Result?param3;
?typedef typename Loki::TL::TypeAtNonStrict<_typelist,3>::Result?param4;
?typedef typename Loki::TL::TypeAtNonStrict<_typelist,4>::Result?param5;

?any(param1 param):
??m_param1(param){}

?any(param2 param):
??m_param2(param){}

?any(param3 param):
??m_param3(param){}

?any(param4 param):
??m_param4(param){}

?template<typename _Ty>
?const _Ty&??Get()
?{
???? class?CERROR_ACCESS_DENIED;
???? LOKI_STATIC_CHECK((Loki::TL::IndexOf<_typelist,_Ty>::value != -???? 1),CERROR_ACCESS_DENIED);

???? return?__Access<_Ty>();
?}
private:
?template<typename _Ty>
?_Ty&? __Access();

?template<>
?param1& __Access<param1>() {return m_param1;}

?template<>
?param2& __Access<param2>() {return m_param2;}

?template<>
?param3& __Access<param3>() {return m_param3;}

?template<>
?param4& __Access<param4>() {return m_param4;}

?param1??m_param1;
?param2??m_param2;
?param3??m_param3;
?param4??m_param4;
};

typedef any<Loki::TYPE_LIST_3(int,float,char)>?ANY;

abstract factory.感覺是個很玄的名字，即使在我寫學習筆記的時候，我也因為缺少現(xiàn)實中的實踐而對其了解不深。^^希望.... 多指正
Name:
?? abstract factory
Addressed Problem:
?? 提供對同1種相關對象的創(chuàng)建。比如在程序里面，希望根據(jù)用戶配置來設置UI方案，比如方案1和2，對應的UI也存在2套不同的實現(xiàn)類，比如對于ScrollBar,有CScrollBar1和CScrollBar2，都繼承自ScrollBar。也許在程序里面有很多這樣的類。這樣你在應用UI實例化類時就必須要選擇比如
IScrollBar* pScrollBar = NULL;
if (_use_ui_1)
?? pScrollBar = new CScrollBar1;
else
?? pScrollBar = new CScrollBar2;
也許你這樣感覺沒多大關系，但想象下，在程序的多處都存在這樣的選擇，為什么我不選擇一種less error phone的方法呢？比如
pScrollBar = Create(...);
這樣一種簡單的方式呢？而且上面的寫法也引進了1個避短，也就是在產(chǎn)生pScrollBar時，涉及到了具體的實現(xiàn)類，這在面向?qū)ο筮@種program to interface這樣的語言中是很忌諱的事情。比如，在加種UI方案，也許你會再寫個else,這樣等于自己把自己往火堆里面推。你是一個勤奮的程序員，但不是個優(yōu)秀的程序員^^.也許有人會說，我可以利用prototype這樣的方式來啊。這樣，在程序的外面配置一下每個類的prototype就可以了，或許也可以用object factory啊，都可以（^^似乎是哦，我也沒學過這2個的說）解決上面的問題，一個通過DoClone類似的，1個通過ID或其他的，其實在應用上面的2種時，自然的導出了abstract factory.為什么呢，因為上面的2種，你都需要設置多個的原型或ID。比如也許在CUIManager的構(gòu)造里面寫賊大的if
if (_use_ui_1)
{
??? ...//設置UI_1下所有的prototype
}
else
{
??? ...//設置UI_2下所有的prototype
}
也許在將來的莫天，在加上UI_3,則。再寫個if.也許大家可能會想，我在應用ui時，我就知道了所要創(chuàng)建的對象，為什么我不把上面寶裝一下改成：
if (_use_ui_1)
?//設置factory_1
else
?//設置factory_2
然后在抽象出來的IFactory里面提供創(chuàng)建這些UI Class的方法，比如，CreateScrollBase.等等，這樣就有了abstract factory 的雛形。
基礎實現(xiàn)
/*
?測試abstract factory模式
*/

class?IScrollWindow
{
public:
?virtual void?DrawScroll(void) = 0;
};

class?IListWindow
{
public:
?virtual?void?DrawList(void) = 0;
};

class?ICreateWindowFactory
{
public:
?virtual?IScrollWindow*?CreateScrollWindow(void) = 0;

?virtual?IListWindow*?CreateListWindow(void) = 0;
};

class?CBlueWindowFactory:
?public?ICreateWindowFactory
{
?class?CBlueScrollWindow:
??public?IScrollWindow
?{
?public:
??virtual void?DrawScroll(void)
??{
???std::cout << "draw blue scroll" << std::endl;
??}
?};

?class?CBlueListWindow:
??public?IListWindow
?{
?public:
??virtual?void?DrawList(void)
??{
???std::cout << "draw blue list" << std::endl;
??}
?};
public:
?virtual?IScrollWindow*?CreateScrollWindow(void)
?{
??return?new CBlueScrollWindow;
?}

?virtual?IListWindow*?CreateListWindow(void)
?{
??return?new CBlueListWindow;
?}
};

class?CRedWindowFactory:
?public?ICreateWindowFactory
{
?class?CRedScrollWindow:
??public?IScrollWindow
?{
?public:
??virtual void?DrawScroll(void)
??{
???std::cout << "draw red scroll" << std::endl;
??}
?};

?class?CRedListWindow:
??public?IListWindow
?{
?public:
??virtual?void?DrawList(void)
??{
???std::cout << "draw red list" << std::endl;
??}
?};
public:
?virtual?IScrollWindow*?CreateScrollWindow(void)
?{
??return?new CRedScrollWindow;
?}

?virtual?IListWindow*?CreateListWindow(void)
?{
??return?new CRedListWindow;
?}
};
在需要用的地方，就可以這樣：
ICreateWindowFactory*?pCreateWindow1?= new CBlueWindowFactory;

?pCreateWindow1->CreateListWindow()->DrawList();
?pCreateWindow1->CreateScrollWindow()->DrawScroll();
假如需要用不同的工廠，則更換不會影響到調(diào)用處的代碼。因為掉用工廠的地方是面向接口的。其實abstract factory的理念應該是比較簡單的(^^瞎猜的).基本講完了什么是抽象類工廠，他要解決的一些問題以及怎么解決和1個小而亂的demo代碼段。下面來看下我們怎么泛化這個類工廠，這個會涉及到loki里面的具體實現(xiàn)，大家要加滿油啊，因為泛化類工廠是一件不容易的事情啊。

泛化_1
首先，(^^這部分我也不是很懂)要泛化的是abstract factory的接口，就象上面的CreateScrollWindow和CreateListWindow，在泛化時需要的信息是要創(chuàng)建的同1組對象的相關接口比如IScrollBar,IList等等，在loki里面，要為1個類泛化1組接口，可以通過GenScatterHierarchy來將unit應用到typelist里的每1個類型，并將該類從unit<type>派生，從而得到1組接口。GenScatterHierarchy做了什么呢，他產(chǎn)生了啥呢？具體的可以看morden c++里面的實現(xiàn)。通過GenScatterHierarchy我們得到了我們要得1組接口。下面是loki里面對這個得相關實現(xiàn)
template <class T>
class AbstractFactoryUnit
{
public:
????virtual T* DoCreate(Type2Type<T>) = 0;
????virtual ~AbstractFactoryUnit() {}
};
可以看到，上面定義了2個函數(shù)，而這個類就是我上面說得調(diào)用GenScatterHierarchy時，具現(xiàn)化時對typelist得每個類型應用得template類，而最后產(chǎn)生得也將是類似AbstractFactoryUnit<IScrollBar>的類，我們具體的抽象工廠從這些派生。至于pure dctor這個大家應該都知道啥作用。下面來看Abstract Factory 的泛化：

template
<
????class TList,
????template <class> class Unit = AbstractFactoryUnit
>
class AbstractFactory : public GenScatterHierarchy<TList, Unit>
{
public:
?????typedef TList ProductList;
???????
?????template <class T> T* Create()
?????{
????????Unit<T>& unit = *this;
????????return unit.DoCreate(Type2Type<T>());
?????}
?};
可以看到這個即由GenScatterHierarchy來得到了我們想要的東西。提供了Create的模板函數(shù)，使得我們可以象這樣factory.Create<IScrollBar>()的方便形勢來調(diào)用。ProductList是對于抽象工廠要創(chuàng)建的類型的重命名。方便后面在產(chǎn)生實際的類型時，獲取對應的類型信息，對于DoCreate的參數(shù)，大家應該都明白這是重載用的，那用在哪里呢？下面會介紹。

handle-body,睡死了，但還是得堅持下。其實這個是很簡單的概念
這個也稱呼為pimpl,是private implemention的縮寫，下面涉及到的都叫做pimpl, 那用這個到底有什么好處呢：
1：可以把具體的實現(xiàn)從client端封裝，這樣即使修改實現(xiàn)，只要不修改頭文件，對client端來說，是沒有任何影響的，甚至不改變代碼的2進制特性
2：加速編譯時間，我們知道有時頭文件有太多的實現(xiàn)，會導致包含這個頭文件的其他文件的編譯時間增加，通過pimpl,我們把實現(xiàn)從頭文件移到cpp里面，從而減少了其他包含這個文件的編譯時間，加快編譯速度
3：減少依賴，這個實際上也增加了編譯的速度，可以不對client端暴露一些實現(xiàn)上的頭文件，從而減少了依賴說了這么多，下面來看下一個簡單的pimpl的實現(xiàn)。是用loki的類來實現(xiàn)的。哈哈，睡死了，偷懶
/*.h*/
class CTest
{
public:
??? void Test();
private:?
????Loki::PimplT::Type m_impl;
};
------------------------------------------------------------------- /*.cpp*/
template<>
struct Loki::ImplT
{
public:
?? ?void Test() { std::cout << "test" << std::endl; }
};

void CTest::Test() { return m_impl->Test(); }
上面只是個很簡單很簡單的例子,以至于有些還無法體會到pimpl的作用，但相信在實踐中你會體會到，把原來定義在CTest里面的一些私有的方法，成員，全部挪到ImplT里面時，你會體會到，這個CTest的頭文件里include了很少的頭，他可以說完成了原始的使命，達到了功能性接口的作用，而其他原來定義在頭里的.h,可以全部挪到cpp里了。下面來分析下loki是怎么實現(xiàn)的。可以看到實現(xiàn)pimpl首先需要牽置聲明pre define類，loki通過模板的全特化來實現(xiàn)了這個的隱藏，從而避免了把具體的實現(xiàn)類暴露給client的弊端。下面來看下這個泛化的pre define: template struct ImplT; 哈哈，很簡單，再看上面我的cpp里的定義，大家結(jié)合上面也許就明白了吧，部過，這里需要注意的是，CTest的構(gòu)造函數(shù)要寫后面，不然can;t compile. 但是，為什么具體的實現(xiàn)類是ImplT但，前面的
Loki::PimplT::Type m_impl;
那Loki::PimplT::Type是什么用的，我們知道，假如保存原始的
Loki::ImplT<CTest>* m_impl;
然后new一個,其實這樣只存在1個問題，2個不方便，
1：問題是這樣的原始指針，不能傳播const信息，也就是說，對象CTest轉(zhuǎn)為const的化，他里面的指針類型不是同樣隨著帶有const屬性，也就是說，假如此時指針指向的對象有個函數(shù)，提供了const＆none const的，此時，還是會調(diào)用non const的，所以，外界還是可以通過這個對象來做修改。
2：2個不方便是，你必須對對象實現(xiàn)new和delete.
下面來看下loki是怎么做的
template<class T>
struct ConstPropPtr
{
??????? explicit ConstPropPtr(T* p) : ptr_(p) {}
??????? ~ConstPropPtr() { delete? ptr_; ptr_ = 0; }
??????? T* operator->()??? { return? ptr_; }
??????? T& operator*()??? { return *ptr_; }
??????? const T* operator->() const??? { return? ptr_; }
??????? const T& operator*()? const??? { return *ptr_; }
???
private:
??????? ConstPropPtr();
??????? ConstPropPtr(const ConstPropPtr&);
??????? ConstPropPtr& operator=(const ConstPropPtr&);
??????? T* ptr_;
};

這個類提供了對問題1的解決。下面會講解，主要的點是，對象不同于指針，對象能傳遞const屬性。
下面看下pimlT的定義：
template<class T, template<class> class Ptr = ConstPropPtr>
struct PimplT
{
??????? typedef T Impl;

??????? // declare pimpl
??????? typedef Pimpl<ImplT<T>, Ptr<ImplT<T> > > Type;

??????? // inherit pimpl
??????? typedef PimplOwner<ImplT<T>, Ptr<ImplT<T> > > Owner;
};
可以看到對Type 的定義，下面的owner也不說了，直接到Pimpl,

template
<???
??????? class T,
??????? typename Pointer = ConstPropPtr<T>
>
class Pimpl
{
public:

??????? typedef T Impl;

??????? Pimpl() : ptr_(new T)
??????? {}

??????? ~Pimpl()
??????? {
??????????? typedef char T_must_be_defined[sizeof(T) ? 1 : -1 ];
??????? }

??????? T* operator->()
??????? {
??????????? return ptr_.operator->();
??????? }

??????? T& operator*()
??????? {
??????????? return ptr_.operator*();
??????? }

??????? const T* operator->() const
??????? {
??????????? return ptr_.operator->();
??????? }

??????? const T& operator*() const
??????? {
??????????? return ptr_.operator*();
??????? }

??????? Pointer& wrapped()
??????? {
??????????? return ptr_;
??????? }

??????? const Pointer& wrapped() const
??????? {
??????????? return ptr_;
??????? }

private:
??????? Pimpl(const Pimpl&);
??????? Pimpl& operator=(const Pimpl&);

??????? Pointer ptr_;
};

睡死了，早早結(jié)束