說明：
      本文來自CSDN博客：http://blog.csdn.net/goodluckyxl/archive/2005/01/19/259851.aspx

強制轉化無論從語法還是語意上看，都是c++中最難看的特征之一。但是基于c風格的轉化的語義的不明確性及其一些潛在問題。強制類型轉化最終還是被c++接受了。
1.static_cast運算符號
static_cast<T>(e),stroustrup讓我們可以把它看成隱含轉換的顯示的逆運算。這個是有一定道理的，基于隱式轉化的對象類型我們可以使用static_cast轉化運算符號。它是靜態(tài)的檢測，無法運行時檢測類型，在繼承中尤為突出。
使用范圍
<1>用于所有系統(tǒng)類型之間轉化，不能用于系統(tǒng)類型指針類型轉化
  double t_d = 0;
int t_i= static_cast<int>(t_d); //是合法的轉化
而企圖將double*->int*是不允許的
<2>用于繼承類之間的轉化（含指針），不能用于其他沒有隱式轉化的對象類型之間的轉化
繼承舉例:
class x
{
};
class y: public x
{
};
使用:x t_o_x;
y t_o_y = static_cast<y>(t_o_x); //x* y*轉化也可以進行因為x,y繼承關
//系，類型可以自動隱式轉化使用
   隱式轉化舉例:
class x
{
};
class y
{

public:
    y( x i_x ) {}
};
    x t_o_x;
     y t_o_y = static_cast<y>(t_o_x); //大家看到y(tǒng)構造函數可以對于x類型隱式轉化
//所以可以將x->y，如果企圖將y->x會報錯
2.reinterpret_cast 運算
主要用于對于類型指針類型的強制轉化，some_type* -> special_type*這樣轉化，類型信息可以是不完全的。它允許將任意指針轉化到其他類型指針，也允許任意整數類型到任意指針類型轉化(BT)。這樣導致的結果是極其不安全的，不能安全的應用于其他目的，除非轉化到原來類型。
<1> 使用所有整形可以轉化為任意類型的指針(指針是4字節(jié)的long的東東，那么機器就認為同類型就是可以轉化)
int c;
x* p = reinterpret_cast<x*>(c); //x是自定義的任意類型，當然包括系統(tǒng)類型
<2> 可以對于任意類型指針之間轉化
y* c;
x* p = reinterpret_cast<x*>(c);//x,y代表所有自定義或系統(tǒng)類型
大家可以看到reinterpret_cast的轉化是極度的不負責任的，他只管轉化不檢測是否可以轉化。
<3> const_cast運算符號
這個很簡單從名字大家可以看出來，僅僅為了去掉或著加上const修飾符號。但是對于本身定義時為const的類型，即使你去掉const性，在你操作這片內容時候也要小心，只能r不能w操作，否則還是會出錯。
const char* p = "123";
char* c = const_cast<char*>(p);
c[0] = 1;  //表面上通過編譯去掉了const性，但是操作其地址時系統(tǒng)依然不允許這
//么做。這是一個漏洞吧
<4> dynamic_cast運算符號
Scott Mayers將其描述為用來執(zhí)行繼承體系中：安全的向下轉型或者跨系轉型動作。也就是說你可以，用dynamic_cast將 指向base class的指針或引用轉型為 指向子類的對象的指針或引用。
class B {};  //polymorphic類型含virtual才能dynamic_cast
class D: public B {}
void f( B* pb )
{
    D* pd1 = dynamic_cast<D*>(pb);//如果pb為d類型正確返回，如果不是返回0
    D* pd2 = static_cast<D*>(pb); //不管怎么樣都返回指針有可能指向不合適的對
//象，因為static僅僅靜態(tài)檢測，不能得到運
//行時對象的信息是否真正為D類型
}

反正大家在使用知道怎么用就ok了，c++強制轉化在模板中還是非常有用的，其他時候本人也喜歡用c的轉化方便。^_^

 1class Strategy
 2{
 3public:
 4  //
 5  virtual void Func1(void) = 0;
 6  virtual void Func2(void) = 0;//這兩個接口只是示例
 7  // some other interfaces here
 8};
 9
10class Sub1 : Strategy
11{
12public:
13  void Func1(void)
14  {
15    // do something
16  }
17  void Func2(void)
18  {
19    // do something
20  }
21};
22
23class Sub2 : Strategy
24{
25public:
26  void Func1(void)
27  {
28    // do something
29  }
30  void Func2(void)
31  {
32    // do something
33  }
34};
35
36class Strategy;
37//策略類結構
38class Context
39{
40public:
41  Context(const Strategy* pStrategyObj) : m_pStrategyObj(pStrategyObj) {}
42  // 
43  // 邏輯接口DoAction
44  void DoAction(void)
45  {
46    if (NULL != m_pStragegyObj)
47    {
48      m_pStrategyObj->Func1();
49      m_pStrategyObj->Func2();
50      // 
51    }
52  }
53};

    注意：設計模式中，更提倡優(yōu)先使用組合，而非繼承。詳細原因，也可以從以上模式比較得出。

 該模式也相對簡單。其主要處理的是這類問題：當系統(tǒng)或某些模塊已經成形后，突然需要增加某些功能。而這些功能的增加
在現有的對象中，暫時沒有辦法處理。同時，卻發(fā)現，該功能，其實另一模塊的對象卻可以處理的了。因此，就希望能夠在不修改原
有操作及系統(tǒng)結構的情況下，就自然而然地將該功能實現出來。此時，就可以使用Adapter來處理之。（注：在此，我們強調的是不
去修改原有系統(tǒng)的結構的情況下）。
 就上述問題，Adapter模式有兩種解決方法。一種是通過對象適配來解決。另一種是通過類適配來解決。所謂的對象適配，指
的是，通過引入具有我們需要功能接口的對象（設類為X），在實現處理過程中，我們使用的是X的功能接口，以此來達到我們的需求。
而類適配，則指的是，產生一個新類，讓該新類，繼承自X類，則自然，該新類就會有了X的相關接口。下面看下，這兩種適配的代碼。

對象適配
class X
{
public:
 ...
 virtual func(...);
};

class ObjAdapterObject : public ...
{
public:
 void func(...)
 {
  if (m_pXObj != NULL)
   m_pXObj->func(...);
 }
private:
 X* m_pXObj;
};

類適配
class X的聲明及定義同上。

class ClassAdapterObject: public X, public  ...
{
public:
 ...
};

以下調用就不寫了，你懂得的。