但是有时候，当然，这在任何时代都是极为罕见的，命运也会出于一种奇怪的心情，把自己抛到一个平庸之辈的手中。有时候——这是世界历史上最令人惊奇的时刻——命运之线在瞬息时间内是掌握在一个窝囊废手中。英雄们的世界游戏像一阵风暴似的也把那些平庸之辈卷了进来。但是当重任突然降临到他们身上时，与其说他们感到庆幸，毋宁说他们更感到骇怕。他们几乎都是把抛过来的命运又哆哆嗦嗦地从自己手里失落。一个平庸之辈能抓住机缘使自己平步青云，这是很难得的。因为伟大的事业降临到渺小人物的身上，仅仅是短暂的瞬间。谁错过了这一瞬间，它绝不会再恩赐第二遍。

格鲁希

维也纳会议正在举行。在玩弄权术和互相争吵之中，像一枚嗖嗖的炮弹飞来这样的消息：拿破仑这头被困的雄狮自己从厄尔巴岛的牢笼中闯出来了；拿破仑赶走了国王；军队又都狂热地举着旗帜投奔到他那一边……好像被一只利爪攫住，那些刚刚还在互相抱怨的大臣们又都聚集在一起，他们再次联合起来，彻底击败这个篡权者。威灵顿开始从北边向法国进军，一支由布吕歇尔布统率的普鲁士军，作为他的增援部队从另一方向前进。施瓦尔岑贝格在莱茵河畔整装待发；而作为后备军的俄国军团，正带着全部辎重，缓慢地穿过德国。

拿破仑看清了这种致命的危险。他必须在普鲁士人、英国人、奥地利人联合成为一支欧洲盟军前就将他们分而攻之，各个击破。于是他匆忙把赌注押在欧洲流血最多的战场——比利时。（1815年）6月16日拿破仑大军的先头部队在林尼与普鲁士军遭遇，并将普军击败。这是这头雄狮的第一次猛击，这一击非常厉害，然而却不致命。被击败而并未被消灭的普军向布鲁塞尔撤退。

拿破仑准备向威灵顿的部队进攻。他不允许自己喘息，也不允许对方喘息，因为每拖延一天，就意味着给对方增添力量。17日，拿破仑率领全军到达四臂村高地前，威灵顿这个对手已在高地上筑好工事，严阵以待。拿破仑充分估计到自己面临的各种危险，即布吕歇尔的军队仅仅是被击败，而并未被消灭。这支军队随时可能与威灵顿的军队会合。为了防止这种可能性，他抽调出一部分部队去跟踪追击普鲁士军，以阻止他们与英军会合。

他把这支追击部队交给了格鲁希元帅指挥。格鲁希，一个气度中庸的男子，老实可靠，兢兢业业。他既没有缪拉那样的胆识魄力，也没有圣西尔那样的足智多谋，更缺乏内伊那样的英雄气概。关于他，没有神话般的传说，也没有谁把他描绘成威风凛凛的勇士。他从戎20年，他是缓慢地、一级一级地升到元帅的军衔。拿破仑大概也知道，格鲁希既不是气吞山河的英雄，也不是运筹帷幄的谋士。但是他自己的元帅，一半已在黄泉之下，而其余几位已对这种没完没了的风餐露宿的戎马生活十分厌倦，正怏怏不乐地呆在自己的庄园里呢。所以，拿破仑是出于无奈才对这个中庸的男子委以重任的。

17日上午11时，拿破仑第一次把独立指挥权交给格鲁希元帅。就在这一天，在这短暂的瞬间，唯唯诺诺的格鲁希跳出一味服从的军人习气，自己走进世界历史的行列。拿破仑的命令是清楚的：当他自己向英军进攻时，格鲁希务必率领交给他的三分之一兵力去追击普鲁士军，而且他必须始终和主力部队保持联系。

格鲁希元帅踌躇地接受了这项命令。他不习惯独立行事。只是当他看到皇帝的天才目光，才感到心里踏实，应承下来。格鲁希的部队在瓢泼大雨中出发。

决定世界历史的一瞬间

18日上午11点，炮手们接到命令：用榴弹炮轰击山头上的身穿红衣的英国士兵。接着，内伊——这位“雄中之杰”，率领步兵发起冲锋。从上午11点至下午1点，法军师团向高地进攻，一度占领了村庄和阵地，但又被击退下来，继而又发起进攻。在空旷、泥泞的山坡上已覆盖着1万具尸体。可是除了大量消耗以外，什么也没有达到。双方的军队都已疲惫不堪，双方的统帅都焦虑不安。双方都知道，谁先得到增援，谁就是胜利者。威灵顿等待着布吕歇尔；拿破仑盼望着格鲁希。

但是，格鲁希并未意识到拿破仑的命运掌握在他自己手中，他只是遵照命令于17日晚间出发，按预计方向去追击普鲁士军。因为敌人始终没有出现，被击溃的普军撤退的踪迹也始终没有找到。

正当格鲁希元帅在一户农民家里急急忙忙进早餐时，他脚底下的地面突然微微震动起来。所有的人都悉心细听。从远处一再传来沉闷的、渐渐消失的声音：这是大炮的声音，是远处炮兵正在开炮的声音，不过并不太远，至多只有三小时的路程。这是圣让山上的炮火声，是滑铁卢战役开始的声音。副司令热拉尔急切地要求：“立即向开炮的方向前进！”所有的人都毫不怀疑：皇帝已经向英军发起攻击了，一次重大的战役已经开始。可是格鲁希却拿不定主意。他习惯于唯命是从，他胆小怕事地死抱着写在纸上的条文——皇帝的命令：追击撤退的普军。热拉尔看到他如此犹豫不决，便恳切地请求：至少能让他率领自己的一师部队和若干骑兵到那战场上去。格鲁希考虑了一下。他只考虑了一秒钟。

然而格鲁希考虑的这一秒钟却决定了他自己的命运、拿破仑的命运和世界的命运。格鲁希使劲地摇了摇手说，把这样一支小部队再分散兵力是不负责任的，他的任务是追击普军，而不是其他。就这样，他拒绝了这一违背皇帝命令的行动。而决定性的一秒钟就在这一片静默之中消逝了，它一去不复返，以后，无论用怎样的言词和行动都无法弥补这一秒钟——威灵顿胜利了。

格鲁希的部队继续往前走。随着一小时一小时的过去，格鲁希越来越没有把握，因为令人奇怪的是，普军始终没有出现。显然，他们离开了退往布鲁塞尔去的方向。接着，情报人员报告了种种可疑的迹象，说明普军在撤退过程中已分几路转移到了正在激战的战场。如果这时候格鲁希赶紧率领队伍去增援皇帝，还是来得及的。但他只是怀着愈来愈不安的心情，继续等待着消息，等待着皇帝要他返回的命令。可是没有消息来。只有低沉的隆隆炮声震颤着大地，炮声却愈来愈远。孤注一掷的滑铁卢搏斗正在进行，炮弹便是投下来的铁骰子。

滑铁卢的下午

时间已经到了下午一点钟。拿破仑的四次进攻虽然被击退下来，但威灵顿主阵地的防线显然也出现了空隙。拿破仑正准备发起一次决定性的攻击。这时，他发现东北方向有一股黑的人群迎面奔来。一支新的部队！

所有的望远镜都立刻对准着这个方向。难道是格鲁希大胆地违背命令，奇迹般地及时赶到了？可是不！一个带上来的俘虏报告说，这是布吕歇尔将军的前卫部队，是普鲁士军队。此刻，皇帝第一次预感到，那支被击溃的普军为了抢先与英军会合，已摆脱了追击；而他——拿破仑自己却用了三分之一的兵力在空地上作毫无用处、失去目标的运动。他立即给格鲁希写了一封信，命令他不惜一切代价赶紧与自己靠拢，并阻止普军向威灵顿的战场集结。

与此同时，内伊元帅又接到了进攻的命令。必须在普军到达以前歼灭威灵顿部队。整个下午，向威灵顿的高地发起了一次又一次的冲锋。战斗一次比一次残酷，投入的步兵一次比一次多。但是威灵顿依旧岿然不动。而格鲁希那边却始终没有消息来。内伊元帅已决定把全部队伍都拉上去，决一死战。于是，1万名殊死一战的盔甲骑兵和步骑兵踩烂了英军的方阵，砍死了英军的炮手，冲破了英军的最初几道防线。虽然他们自己再次被迫撤退，但英军的战斗力已濒于殆尽。山头上像箍桶似的严密防线开始松散了。当受到重大伤亡的法军骑兵被炮火击退下来时，拿破仑的最后预备队——老近卫军正步履艰难地向山头进攻。欧洲的命运全系在能否攻占这一山头上。

决战

自上午以来，双方的400门大炮不停地轰击着。前线响彻骑兵队向开火的方阵冲杀的铁蹄声。从四面八方传来的冬冬战鼓声，震耳欲聋，整个平原都在颤动！但是在双方的山头上，双方的统帅似乎都听不见这嘈杂的人声。他们只是倾听着更为微弱的声音。

两只表在双方的统帅手中，像小鸟的心脏似的在嘀嗒嘀嗒地响。这轻轻的钟表声超过所有震天的吼叫声。拿破仑和威灵顿各自拿着自己的计时器，数着每一小时，每一分钟，计算着还有多少时间，最后的决定性的增援部队就该到达了。威灵顿知道布吕歇尔就在附近。而拿破仑则希望格鲁希也在附近。现在双方都已没有后备部队了。谁的增援部队先到，谁就赢得这次战役的胜利。

普军的侧翼终于响起了枪击声。拿破仑深深地吸了一口气：“格鲁希终于来了！”他以为自己的侧翼现在已有了保护，于是集中了最后剩下的全部兵力，向威灵顿的主阵地再次发起攻击。这主阵地就是布鲁塞尔的门闩，必须将它摧毁，这主阵地就是欧洲的大门，必须将它冲破。

然而刚才那一阵枪声仅仅是一场误会。由于汉诺威兵团穿着别样的军装，前来的普军向汉诺威士兵开了枪。但这场误会的遭遇战很快就停止了。现在，普军的大批人马毫无阻挡地、浩浩荡荡地从树林里穿出来。厄运就此降临了。这一消息飞快地在拿破仑的部队中传开。部队开始退却。所有剩下的英军一下子全都跃身而起，向着溃退的敌人冲去。与此同时，普鲁士骑兵也从侧面向仓皇逃窜、疲于奔命的法军冲杀过去。

仅仅几分钟的工夫，这支赫赫军威的部队变成了一股被人驱赶的抱头鼠窜、惊慌失措的人流。在一片惊恐的混乱叫喊声中，他们轻而易举地捕获了拿破仑的御用马车和全军的贵重财物，俘虏了全部炮兵。只是由于黑夜的降临，才拯救了拿破仑的性命和自由。一直到半夜，满身污垢、头昏目眩的拿破仑才在一家低矮的乡村客店里，疲倦地躺坐在扶手软椅上，这时，他已不再是个皇帝了。他的帝国、他的皇朝、他的命运全完了。一个微不足道的小人物的怯懦毁坏了他这个最有胆识、最有远见的人物在20年里所建立起来的全部英雄业绩。

那关键的一秒钟就是这样进行了可怕的报复。在尘世生活中，这样的一瞬间是很少降临的。当它无意之中降临到一个人身上时，他却不知如何利用它。在命运降临的伟大瞬间，市民的一切美德——小心、顺从、勤勉、谨慎，都无济于事，它始终只要求天才人物，并且将他造就成不朽的形象。命运鄙视地把畏首畏尾的人拒之门外。命运——这世上的另一位神，只愿意用热烈的双臂把勇敢者高高举起，送上英雄们的天堂。

 1 #pragma once
 2
 3 class component
 4 {
 5 public :
 6     component(void);
 7   virtual void printsefl() = 0    ;
 8 public :
 9     virtual ~component(void);
10 };
11
12 class concreatecom : public  component
13 {
14 public :
15     concreatecom(char *  );
16   virtual void printsefl()   ;
17   virtual ~concreatecom(void);
18 protected:
19 private :
20 char  *  _psz_text;
21 };
22
23 class decorator: public  component
24 {
25 public :
26      decorator(component & );
27   virtual void printsefl()     ;
28   virtual ~decorator();
29 protected:
30
31 private :
32    component  &  _pcomponent;
33 };
34 class  headdeco: public  decorator
35 {
36 public :
37        headdeco(component & , int );
38    virtual void printsefl()   ;
39    virtual ~headdeco();
40 protected:
41     virtual void printhead()  ;
42 private :
43 int  _i_head;
44 };
45
46 class enddeco: public  decorator
47 {
48 public :
49       enddeco(component & ,char * );
50     virtual void printsefl() ;
51     virtual  ~enddeco();
52 protected:
53       virtual void printend() ;
54 private :
55  char *  _pch_end;
56 };

 1 #include  " StdAfx.h "
 2 #include  < iostream >
 3 #include  " component.h "
 4 using namespace std;
 5
 6 component::component(void)
 7 {
 8 }
 9
10 component::~component(void)
11 {
12 }
13
14 void concreatecom::printsefl() 
15 {
16    cout << endl;
17    cout << _psz_text ;
18    cout << endl;
19 }
20  concreatecom::concreatecom(char *  psz)
21 {
22       _psz_text = psz;
23 }
24  decorator::decorator(component &  a):
25    _pcomponent(a)
26 {
27   
28 }
29 concreatecom::~concreatecom()
30 {
31
32 }
33 void decorator::printsefl()
34 {
35 _pcomponent.printsefl();
36     
37 }
38
39 decorator::~decorator()
40 {
41
42 }
43
44  headdeco::headdeco(component  &  refcom,  int  i):
45   decorator(refcom)
46  ,_i_head(i)
47 {
48
49 }
50 void headdeco::printsefl() 
51 { 
52    printhead();
53    decorator::printsefl();
54    
55 }
56 void headdeco::printhead() 
57 {
58     cout << endl;
59    cout << _i_head;
60    cout << endl;
61 }
62 headdeco::~headdeco()
63 {
64  
65 }
66
67 enddeco::enddeco(component  &  refcom,char  *  pch)
68 :decorator(refcom)
69 ,_pch_end(pch)
70 {
71    
72 }
73 void enddeco::printsefl() 
74 {
75     decorator::printsefl();
76     printend();
77 }
78 void enddeco::printend()  
79 {
80     cout << endl;
81     cout << _pch_end;
82     cout << endl;
83 }
84 enddeco::~enddeco()
85 {
86
87 }

 1 //  decorator.cpp : 定义控制台应用程序的入口点。
 2 //
 3
 4 #include  " stdafx.h "
 5 #include  < iostream >
 6 #include  " component.h "
 7 using namespace std;
 8
 9  void printmodel(component &  pcom )
10 {
11     pcom.printsefl();
12 }
13 int  _tmain( int  argc, _TCHAR *  argv[])
14 {
15      
16     printmodel(headdeco(headdeco(enddeco(concreatecom( " 正文输出中。。。。 " ), " 黄大仙 " ), 2 ), 1 ));
17     return  0 ;
18 }
19

       这个decorator 模式例子让初学者 更能加深 多态威力的体会和 decorator 模式 比子类灵活的体会
要注意的问题是：对象链总是在 concreatecomponent  对象处结束。

  ///此处是client 使用 对象的入口点，仅仅得到了 1个 decorator 的派生类对象，client 什么都不知道
printmodel(headdeco(headdeco(enddeco(concreatecom("正文输出中。。。。"),"黄大仙"),2),1));
///

     在vc2005 下通过

Elements inserted into an STL container can be of any object type that supplies a public copy constructor, a public 
                                      public 拷贝构造 ，public 析构 ,public 赋值操作符   elem& operator =( elem const &)
destructor, and a public assignment operator. The destructor may not throw an exception. Furthermore, associative 
                                                                       析构不能抛出异常
containers such as set and map must have a public comparison operator defined, which is operator< by default. Some 
                             关联容器  除此外 还应由有 比较操作符
                  operations on containers might also require a public default constructor and a public equivalence operator.




以下是  各容器 迭代器类型输出代码

 1#include <vector>
 2#include <list>
 3#include <deque>
 4#include <set>
 5#include <map>
 6using namespace std;
 7template <typename inputitrator >
 8void predict(inputitrator  a)
 9{   iterator_traits<inputitrator>::iterato_category  b;
10   
11   cout<< endl<< "  "<<typeid(b).name();
12}
13
14
15main()
16
17{
18  vector<int> a;
19  deque<int> b;
20  list<int> c;
21  set<int> d;
22  map<int> e;
23  
24   predict(a.begin());
25   predict(b.begin());
26   predict(c.begin());
27    predict(d.begin());
28     predict(e.begin());
29
30}

output iterator
   -> forward iterator
   -> bidirectional iterator
   -> random-access iterator

input iterator
   -> forward iterator
   -> bidirectional iterator
   -> random-access iterator

class B { ... };
class C : public B { ... };
class D : public C { ... };

void f(D* pd)
{
   C* pc = dynamic_cast<C*>(pd);   // ok: C is a direct base class
                                 // pc points to C subobject of pd 

   B* pb = dynamic_cast<B*>(pd);   // ok: B is an indirect base class
                                 // pb points to B subobject of pd 
   ...
}

This type of conversion is called an "upcast" because it moves a pointer up a class hierarchy, from a derived class to a class it is derived from. An upcast is an implicit conversion.

If type-id is void*, a run-time check is made to determine the actual type of expression. The result is a pointer to the complete object pointed to by expression. For example:

class A { ... };

class B { ... };

void f()
{
   A* pa = new A;
   B* pb = new B;
   void* pv = dynamic_cast<void*>(pa);
   // pv now points to an object of type A
   ...
   pv = dynamic_cast<void*>(pb);
   // pv now points to an object of type B
}

If type-id is not void*, a run-time check is made to see if the object pointed to by expression can be converted to the type pointed to by type-id.

If the type of expression is a base class of the type of type-id, a run-time check is made to see if expression actually points to a complete object of the type of type-id. If this is true, the result is a pointer to a complete object of the type of type-id. For example:

class B { ... };
class D : public B { ... };

void f()
{
   B* pb = new D;                     // unclear but ok
   B* pb2 = new B;

   D* pd = dynamic_cast<D*>(pb);      // ok: pb actually points to a D
   ...
   D* pd2 = dynamic_cast<D*>(pb2);   // pb2 points to a B not a D
                                    // cast was bad so pd2 == NULL
   ...
}

This type of conversion is called a "downcast" because it moves a pointer down a class hierarchy, from a given class to a class derived from it.
小结：
  a     实际指向对象 和   b 目标对象,  b 是a 的 基类（子对象），或者是2者 同级转换才成功
否则 目标为NULL;也就是说不能向下转



2   多重非虚的继承模式

Class Hierarchy Showing Multiple Inheritance

A pointer to an object of type D can be safely cast to B or C. However, if D is cast to point to an A object, which instance of A would result? This would result in an ambiguous casting error. To get around this problem, you can perform two unambiguous casts. For example:

void f()
{
   D* pd = new D;
   A* pa = dynamic_cast<A*>(pd);      // error: ambiguous
   B* pb = dynamic_cast<B*>(pd);      // first cast to B
   A* pa2 = dynamic_cast<A*>(pb);   // ok: unambiguous
}

Further ambiguities can be introduced when you use virtual base classes. Consider the class hierarchy shown in the following figure.

    也就是说在2意性下会失败
3.子对象间的转换

Class Hierarchy Showing Duplicate Base Classes

    //pd 指向 e 对象
void f(D* pd)
{
   E* pe = dynamic_cast<E*>(pd);
   B* pb = pe;      // upcast, implicit conversion
   A* pa = pb;      // upcast, implicit conversion
}

//pd 指向 e 对象
void f(D* pd)
{
   B* pb = dynamic_cast<B*>(pd);      // cross cast
   A* pa = pb;                  // upcast, implicit conversion
}

  也就是  所谓 cross cast

二  typeid( type-id )     typeid( expression ) 
   此操作符返回个  const type_info & 
            expression 必须指向一个多态类型（带虚函数    ），并且要解引用

#include <iostream>
#include <typeinfo.h>

Windows objects are normally represented by HANDLEs. The MFC classes wrap Windows object handles with C++ objects. The handle wrapping functions of the MFC class library provide a way to find the C++ object that is wrapping the Windows object with a particular handle. There are times when a Windows object does not have a C++ wrapper object, however, and at these times a temporary object is created to act as the C++ wrapper.

mfc 映射的 windows object ---->c++ wrapper
以下使用 mfc 的函数 如：fromhandle, getdlgitem,都会返回temporary 和 pemanent  c++ wrapper object
 注意：
     零时的 对象 会被在空闲时(OnIdle()函数)被删除，不能存下在下次消息处理中 使用
The default OnIdle processing in CWinThread automatically calls DeleteTempMap for each class that supports temporary handle maps
////////////////////////////////////////////////////////////
The Windows objects that use handle maps are:

• HWND (CWnd and CWnd-derived classes)
• HDC (CDC and CDC-derived classes)
• HMENU (CMenu)
• HPEN (CGdiObject)
• HBRUSH (CGdiObject)
• HFONT (CGdiObject)
• HBITMAP (CGdiObject)
• HPALETTE (CGdiObject)
• HRGN (CGdiObject)
• HIMAGELIST (CImageList)
• SOCKET (CSocket)

///////////////////////////////////////////////

Given a handle to any of these objects, you can find the MFC object that wraps the handle by calling the static member function FromHandle. For example, given an HWND called hWnd:

CWnd::FromHandle(hWnd)

will return a pointer to the CWnd that wraps the hWnd. If that hWnd does not have a specific wrapper object, then a temporary CWnd is created to wrap the hWnd. This makes it possible to get a valid C++ object from any handle.

Once you have a wrapper object, you can get to its handle through a public member variable. In the case of a CWnd, m_hWnd contains the HWND for that object.

Attaching Handles to MFC Objects

Given a newly created handle-wrapper object and a handle to a Windows object, you can associate the two by calling Attach. For example:

CWnd myWnd;
myWnd.Attach(hWnd);
  ////mywnd 析构时会调用 destroywindow ,连同 hwnd 一起销毁

This makes an entry in the permanent map associating myWnd and hWnd.
Calling CWnd::FromHandle(hWnd) will now return a pointer to myWnd.
When myWnd is deleted, the destructor will automatically destroy the hWnd by calling the Windows DestroyWindow function. If this is not desired, the hWnd must be detached from myWnd before the myWnd object is destroyed (normally when leaving the scope at which myWnd was defined). The Detach member function does this.

myWnd.Detach();

More About Temporary Objects

Temporary objects are created whenever FromHandle is given a handle that does not already have a wrapper object. These temporary objects are detached from their handle and deleted by the DeleteTempMap functions. The default OnIdle processing in CWinThread automatically calls DeleteTempMap for each class that supports temporary handle maps. This means that you cannot assume a pointer to a temporary object will be valid past the point of exit from the function where the pointer was obtained, as the temporary object will be deleted during the Windows message-loop idle time.

很重要:
在多线程中传递 c++ wrapper object 是无效的(无论是 temporary 还是 permanent)
只能传递 windows handle, 换句话就是说， 线程 只能 访问 自己创建的c++ wrapper object

Wrapper Objects and Multiple Threads

Both temporary and permanent objects are maintained on a per-thread basis. That is, one thread cannot access another threads C++ wrapper objects, regardless of whether it is temporary or permanent. As stated above, temporary objects are deleted when the thread which that temporary object belongs enters OnIdle.

To pass these objects from one thread to another, always send them as their native HANDLE type. Passing a C++ wrapper object from one thread to another will often result in unexpected results.

template<class RandomAccessIterator> inline   void make_heap(      RandomAccessIterator First,      RandomAccessIterator Last   )template<class RandomAccessIterator> inline   void sort_heap(      RandomAccessIterator First,      RandomAccessIterator Last   )template<class RandomAccessIterator> inline   void push_heap(      RandomAccessIterator First,      RandomAccessIterator Last   )template<class RandomAccessIterator> inline   void pop_heap(      RandomAccessIterator First,      RandomAccessIterator Last   )