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

格鲁希

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

拿破仑看清了这种致命的危险。他必须在普鲁士人、英国人、奥地利人联合成为一支欧洲盟军前就将他们分而攻之，各个击破。于是他匆忙把赌注押在欧洲流血最多的战场——比利时。（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   )

标准库 

当我还在研究院工作时，与同院另外两家研究所合作开发过一个大型水利枢纽调度集成项目。我们三家软件系统之间都要相互通信。在调试通讯模块时，细心的客户（一名好学的系统管理员）发现对于同一通信规约的解释代码，我的不超过30行，而对方的则超过了150行且很难看懂。这位系统管理员很纳闷，我说大家编程风格和习惯不一样，我使用了标准库，而他使用了传统C编程风格以及他所习惯的另外一些技术。 

别误会！我绝无贬低这位合作伙伴的意思。事实上，我对那些真正有着深厚的C编程功力的程序员常常怀有钦佩之心。毕竟，C++能有今天的成功在很大程度上缘于它深深地植根于C。作为一名C++程序员，倘若不熟悉C++中的C，我往往会认为他的基本功是不扎实的，他的技术底气是不足的。 

不过话又说回来，C++是一种多范型（paradigm）编程语言，具体采用哪种编程风格，专业程序员应该知道视具体情况而定。作为一名经常需要在现场做即兴开发的项目负责人，为了短平快地解决当务之急，我习惯尽量采用现有的库（和组件）。效率（以及强健性）久经验证的C++标准库已经摆在那儿了，何乐而不用呢？ 

Nicolai M. Josuttis, The C++ Standard Library: A Tutorial and Reference
《C++标准程序库：自修教程与参考手册》，华中科技大学出版社

这是一本百科全书式的C++标准库著作，是一本需要一再查阅的参考大全。它在完备性、细致性以及精确性方面都是无与伦比的。本书详细介绍了每一标准库组件的规格和用法，内容涵盖包括流和本地化在内的整个标准库而不仅仅是STL。正如本书副标题所示，它首先适合作为教程阅读，尔后又可用作参考手册。

浅显易懂的写作风格使得这本书非常易读。如果你希望学习标准库的用法并尽可能地发挥其潜能，那你必须拥有这本书。正如网络上所言，这本书不仅仅应该摆在你的书橱中，更应该放到你的电脑桌上。我向每一位职业C++程序员强烈推荐。

Angelika Langer, Klaus Kreft, Standard C++ IOStreams and Locales: Advanced Programmer's Guide and Reference
《标准C++输入输出流与本地化》，人民邮电出版社

C++标准库由STL、流和本地化三部分构成。关于STL的书市面上已经有不少，但罕见流和本地化方面的专著。本书是这两个领域中最优秀的一本，迄今为止没有任何一本书比这一本更全面详尽地讨论了流和本地化。如果你不满足于停留在“会用”流库的层面，千万不要错过它。

2001年夏天，我草草翻阅过这本书的中文版，从内容到包装都给我留下了比较深刻的印象 — 不过负面的居多一些。2003年秋天，无意中得知某网络书店正以超低价格甩卖这本书的中译本，情不自禁，一阵唏嘘。

Scott Meyers, Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library
《Effective STL（影印版）》，中国电力出版社

读完Scott 的《Effective C++》和《More Effective C++》的中译本之后，我一直期待这本书的中文版。我从潘爱民先生的个人主页上了解到，他和他的合作伙伴似乎早已完成了这本书的翻译工作，可惜至今市面上仍不得见。幸运的是，我们可以看到它的原版。

本书是使用STL的程序员必读之作。在这本书中，Scott向我们讲述STL容器和算法的工作机制以及如何以最佳方式使用它们。和Scott的其他作品一样，这本书的写作风格清晰、精确，具有极佳的可读性。看过这本书以后，我想你也许会和我以及其他C++程序员一样产生这样的想法：Scott什么时候会写出一本“More Effective STL”？

关于STL，我还提醒你留心Matthew H. Austern的《Generic Programming and the STL: Using and Extending the C++ Standard Template Library》（《泛型编程与STL》，中国电力出版社）。这本书散发着浓厚的学院气息。Andrew Koenig和Barbara Moo在《Accelerated C++: Practical Programming by Example》一书末尾郑重推荐另外两本进阶好书（除了他们自己的《Ruminations on C++》外），其中一本是TCPL，另外一本就是本书！

网络编程

在网络编程时代，C++应该扮演着怎样的角色，让ACE（Adaptive Communications Environment）来告诉你。

Douglas C. Schmidt, Stephen D. Huston, C++ Network Programming, Volume 1: Mastering Complexity with ACE and Patterns
Douglas C. Schmidt, Stephen D. Huston, C++ Network Programming, Volume 2: Systematic Reuse with ACE and Frameworks
《C++网络编程，卷1：运用ACE和模式消除复杂性》，华中科技大学出版社
《C++网络编程，卷2：基于 ACE 和框架的系统化复用》，电子工业出版社

采用C++进行企业级网络编程，目前ACE（以及这两本书）是一个值得考虑的选择。ACE是一个面向对象、跨平台、开放源码的网络编程框架，目标在于构建高性能网络应用和中间件。Douglas是ACE的创始人，Stephen则已为ACE提供了数年的技术支持和顾问服务，两位都是ACE社群（是的，ACE的影响和实际应用的程度已经形成了一个社群）的专家。

ACE并不单单被大学和研究所追捧，它已经被成功地应用于世界上成千上万个商业应用中。在电信、宇航、医药和财经领域的网络系统中，ACE已经并继续发挥着重要的作用。如果你准备开发高性能通讯系统，你应该考虑考虑这一汇集世界顶尖专家智慧的成果。

除了使用C++面向对象设计技术和模板等高级语言特性外，ACE还运用了大量的模式。《C++网络编程》卷1和卷2并不仅仅教你关于ACE的方方面面，它还会教给你模式和通用框架设计等高级技术等。所以，作为一名中、高级C++程序员，即使你很少进行正儿八经的C++网络程序设计，阅读这两本书同样可以从中受益。

是的，并非所有网络应用都要使用Web服务器（以及其他应用服务器）和重量级组件模型，换个思路，它们或许也可以从轻量级的ACE组件中获益。

杂项

以下这几本书之所以被列入“杂项”单元，只是因为我没有考虑出更合适的归类方法，它们和上面的书籍一样，值得一读。

Bruce Eckel, Thinking in C++, Volume 1: Introduction to Standard C++ (2nd Edition)
Bruce Eckel, Thinking in C++, Volume 2: Practical Programming (Second Edition)
《C++编程思想（第2版）第1卷：标准C++导引》，机械工业出版社
《C++编程思想（英文版 第2版）》，机械工业出版社

《Thinking in C++》的第1版于1996年荣获“软件研发”杂志评选的图书震撼大奖。最新推出的第2版对内容进行了大幅改写和调整，以反映C++标准化带来的影响以及近几年面向对象领域最新研究和实践成果。“输入输入流”、“多重继承”、“异常处理”和“运行时类型识别”等高级主题连同C++标准化以后增加的一些内容则被放入第二卷中。Bruce是一名经验丰富的C++讲师和顾问，其培训和写作经验都是世界一流水准，他的作品比那些“玩票”的技术人员写的东西更能吸引读者。事实上，在同类图书中，对于大多数读者而言，这本书的可读性要超过TCPL和《C++ Primer》。顺带一提，访问作者的站点，你可以先睹第二卷的风采。

Andrew Koenig, Barbara E. Moo, Ruminations on C++: A Decade of Programming Insight and Experience
《C++沉思录》，人民邮电出版社

Andrew是世界上屈指可数的C++专家。这是一本关于C++编程思想和程序设计技术而非语言细节的著作。如果你已经具有一定的基础，这本书将教你在进行C++编程时应该怎样思考，应该如何表达解决方案。整本书技术表达透彻，文字通俗易懂。Bjarne这样评价这本书：本书遍布“C++是什么、C++能够做什么”的真知灼见。

Stanley B. Lippman, Inside The C++ Object Model
《深度探索C++对象模型》，华中科技大学出版社
《深度探索C++对象模型（影印版）》，中国电力出版社

从编译器的角度观察C++可以使你知其然并知其所以然。本书探讨了大量的C++面向对象程序设计的底层运作机制，包括构造函数、函数、临时对象、继承、虚拟、模板的实例化、异常处理、运行期类型识别等，另外还介绍了一些在实现C++对象模型过程中做出的权衡折衷。喜欢刨根问底的C++程序员不要错过这本书。

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Elements of Reusable Object-Oriented software
《设计模式：可复用面向对象软件的基础》，机械工业出版社
《设计模式：可复用面向对象软件的基础（英文版）》，机械工业出版社

设计可复用的面向对象的软件，你需要掌握设计模式。本书并非专为C++程序员而写，但它采用了C++（以及Smalltalk）作为主要示例语言，C++程序员尤其易于从中受益。四位作者都是国际公认的面向对象软件领域专家，他们将面向对象软件的设计经验作为设计模式详细记录下来。这本书影响是如此深远，以至于四位作者以及本书都被昵称为GoF（Gang of Four）。本书学院气息浓厚，行文风格严谨简洁，虽然它不如某些讲解模式的书籍易读，但真正要精准地理解设计模式，本书是终极权威。学习设计模式，这本书需要一而再、再而三的咀嚼。顺带一句：请将设计模式化作开拓思维的钥匙，切莫成为封闭思维的枷锁。

还有一些C++好书值得一读，恕此处无法一一列出。例如John Lakos的著作《Large-Scale C++ Software Design》（《大规模C++程序设计》，中国电力出版社）和侯捷先生的《STL 源码剖析》（华中科技大学出版社）等。

《STL 源码剖析》是一本很有特色的书，但我认为它还可以更好。我个人期待侯捷先生自第一版发行以来经过对模板技术的沉淀和再思考之后，再写一本剖析得更深入、更透彻并且更全面的“第二版”。遗憾的是，侯捷先生在完成《C++ Templates: The Complete Guide》一书的翻译后似乎决定暂时告别模板、泛型编程和STL领域。

2004年3月31日补充：我目前最常查阅的两本参考书是《C++标准程序库》和《STL源码剖析》。当然了，这与我年内的写作计划有很大的关系。

使用C++成功开发大规模软件系统，不仅需要很好地理解大多数C++书籍中讲述的逻辑设计问题，更需要掌握《大规模C++程序设计》中讲述的物理设计技术。当然，这本书的确有点过时了，不过，如果你的精力和金钱都比较宽绰，买一本看看并无坏处。

至此，我想有必要声明一下，有一些（好）书没有得到推荐，主要原因如下：

    * 以上这些书已经足够多、足够好了。
    * 我不会推荐通过正常渠道很难购买到的书籍 — 不管是中文版还是英文版。
    * 作（译）者名气大小不影响我的推荐。我们是在看书，不是看人。
    * 我不会推荐我从来没有看过的书。我至少要看过其中的某个版本（包括电子档）。这个“看”，一般指“认真阅读”，不过有一些也只能算是“浏览”。

结语

作为一名普通技术写译者，我深知技术创作和翻译的艰辛（和快乐），并多多少少了解一些有关技术书籍创作、翻译、制作、出版以及市场推介背后的细节。今天，我不会再对一本看上去差强人意的图书信口开河。罗列同一本书的各种版本的用意只在于为你多提供一些信息，让你多一种选择。

在本文成文的后期，我给Bjarne写了一封信，请教如果他来写这篇文章会怎么写。他给了我简明扼要的建议。在肯定以上列出的绝大部分图书都是世界顶尖水平的C++著作的同时，Bjarne提醒我别忘了向专家级程序员推荐《The C++ Standard : Incorporating Technical Corrigendum No. 1》。这本书是 C++标准规范的“图书版”，Bjarne亲自为之作序。

Bjarne还友好地提醒我，在我的推荐列表中没有哪一本有助于C++程序员进行Windows编程 — 这正是我的本意。在这篇文章中，我只推荐、点评平台中立的C++著作（网络编程除外） — 和操作系统无关，和集成开发环境无关，我甚至幻想它们和编译器也无关。你可以根据业务开发需要，选读自己喜爱的领域相关的C++书籍。

说到“系统无关、平台中立”，我不由得想起了“抽象层”的概念。开发实际应用的C++程序员通常工作于特定操作系统、特定开发环境和特定业务领域之中，而对标准C++和C++标准库扎实而深刻的把握，无疑是你得以在不同的操作系统、不同的开发环境以及不同的业务领域之间纵横驰骋的“抽象”本钱。 

然而，一个不可否认的现实是，在低阶程序设计领域，C++挤压着C同时也在承受着C的强烈反弹，而在高阶程序设计领域，Java和C#正在不断蚕食着C++的地盘。也许C++与C合为一体永远都是一个梦想，也许Java和C#的狂潮终将迫使C++回归本位 — 回到它有着根本性优势的开发领域：低级系统程序设计、高级大规模高性能应用设计、嵌入式程序设计以及数值科学计算等。果真如此，我认为这未尝不是一件好事。

C++吸引如此之多的智力投入，以至于这个领域的优秀作品，包括重量级的软件产品、程序库以及书籍等，数不胜数。文题“C++程序设计之四书五经”一个不太严格的含义是：C++程序设计之四书 ⅹ 五经。是的，在本文（及其下篇）中，我将分门别类推荐20多本C++好书，你可以根据自己的需要选读。

TCPL和D&E

TCPL和D&E分别是《The C++ Programming Language》和《The Design and Evolution of C++》的简称，均出自Bjarne Stroustrup之手。我将它们单列出来，首先是因为Bjarne是C++语言的创建者，然后是因为比“首先”那个原因更重要的原因：这两本书是C++领域毋庸置疑的杰作。说它们是C++语言圣经，并不为过。

Bjarne Stroustrup, The C++ Programming Language (Special 3rd Edition)
《C++程序设计语言（特别版）》，机械工业出版社
《C++程序设计语言（特别版）（英文影印版）》，高等教育出版社

迄今为止，TCPL是除了C++标准文献之外最权威的C++参考手册。和大多数人的看法不大一样，我认为Bjarne的文字语言并不逊色于他所创建的程序语言，至少我喜欢这种学院气息浓厚的作品。本书对C++语言的描述轮廓鲜明、直截了当。它从C++语言创建者的角度来观察C++，这是任何别的作者和书籍做不到的 — 没有任何人比Bjarne自己更清楚该怎么来使用C++。

这是一本严肃的著作，以中、高级C++开发人员为目标读者。如果你是一名有经验的C++程序员，需要了解更加本质的C++知识，本书正是为你而写。它不是那种让你看了会不断窃喜的小书，需要用心体会，反复咀嚼。在阅读过程中，请特别留心Bjarne先生强调了什么，又对什么一语带过。我个人比较喜欢这本书的第四部分“使用C++做设计”，这样的内容在类似的程序设计语言书籍中很难看到 — 我甚至认为Bjarne应该将这部分独立出来单独写一本书。

Bjarne Stroustrup, The Design and Evolution of C++
《C++语言的设计和演化》，机械工业出版社
《C++语言的设计和演化（英文版）》，机械工业出版社

D&E是一本关于C++语言设计原理、设计决策和设计哲学的专著。它清晰地回答了C++为什么会成为今天这个样子而没有变成另外一种语言。作为C++语言的创建者，Bjarne淋漓尽致地展示了他独到而深刻的见解。除了广受赞誉的语言特性外，Bjarne没有回避那些引起争议的甚至被拒绝的C++特性，他一一给出了逻辑严密、令人信服的解释。内容涵盖C++的史前时代、带类的C、C++的设计规则、标准化、库、内存管理、多重继承、模板等，对包括异常机制、运行时类型信息和名字空间在内的重要的新特性都分别进行了深入探讨。每一名C++程序员都应该可以从Bjarne的阐释中加深对手中这门语言的认识。

需要再次提醒的是，这两本书知识浓缩，信息量极大，请不要错过Bjarne每一句看似漫不经意的话。

入门教程

学习任何一门语言都需要一个从入门到精通、从新手到高手循序渐进的过程。不过，对于一个所谓的新手而言，究竟是一个完完全全的新手，还是一个熟悉某种别的语言的“新手”，甚至是在某种语言程序设计领域已经颇有建树的高手，很难一概而论？不同的C++新手需要不同的入门书籍。

Andrew Koenig, Barbara E. Moo, Accelerated C++: Practical Programming by Example
《Accelerated C++中文版》，中国电力出版社

和市面上大多数C++教程不同，本书不是从“C++中的C”开始讲解，而是始于地道的C++特性。从一开始就使用标准库来写程序，随着讲述的逐渐深入，又一一解释这些标准库组件所依赖的基础概念。另外，和其他C++教材不同的是，这本书以实例拉动语言和标准库的讲解，对后两者的讲解是为了给实例程序提供支持，而不是像绝大多数C++教材那样，例子只是用作演示语言特性和标准库用法的辅助工具。

作者在C++领域的编程实践、教育培训以及技术写作方面都是世界一流水准。我喜欢这种大量使用标准库和C++语言原生特性的清新的写作风格。在这本教材面前，几乎迄今为止的所有C++教材都黯然失色或显得过时。尽管这本教材也许对于国内的高校教育来说有些前卫，不过我仍然极力向我的同行们推荐。顺带一提，在Bjarne和我最近的一封通信里，他这样评价本书：对于有经验的程序员学习C++而言，这本书可能是世界上最好的一本。

Stanley B.Lippman, Josee Lajoie, C++ Primer (3rd Edition)
《C++ Primer (3RD)中文版》，中国电力出版社

这本书的名字多少有点让人误解。尽管作者声称这本书是为C++新手而写，但无论是它的厚度还是讲解的深度都暴露了似乎并非如此。也许说它是一本“从入门到精通”的C++教程会更合适一些。我个人认为它并不适合完全不懂C++的初学者 — 在阅读这本书之前，你至少应该先有那么一点C或C++的背景知识，或者至少要具有一些其他语言的编程经验。

尽管这本书省略了一些高级C++特性的讨论，但仍然可以称得上是迄今为止最全面的C++学习教程。事实上，如果一名C++初学者能够扎扎实实地读完本书并对照《C++ Primer Answer Book》完成全部习题的话，他的水平肯定可以进入职业C++程序员的行列。我个人认为，即使你已经拥有了TCPL，这本书依然有拥有的价值，因为在许多方面它比TCPL来得更详细、更易懂。

Stanley B. Lippman, Essential C++
《Essential C++中文版》，华中科技大学出版社
《Essential C++（影印版）》，中国电力出版社

可以不太严格地认为这本书是《C++ Primer》的精简版。本书一一讲述了C++中最具代表性的主题，包括过程式编程、泛型编程、基于对象编程、面向对象编程、模板编程以及异常处理等。Stanley将门槛调低到“具有其他语言程序设计经验”的C++新手所能接受的最基本的层次，使他们能够迅速开始使用C++编程而又免于阅读《C++ Primer》那样的大部头。它以实例引导学习，力图使读者在最短的时间内把握C++的精粹。

也许换一个人来概述C++编程范型（paradigm）的方方面面需要好几百页才能说清楚，但这本小书不可思议地做到了这一点。我个人非常喜欢这种满是技术、简明扼要并且“有话好好说”的书。这本书同样具有一个明显的风格：所有程序例子全部采用标准库组件，让人耳目一新。

以上三本书都不是为了完完全全的编程新手而写。完全的C++编程新手可以阅读Francis Glassborow的新书（尚未出版）：《A Beginners Introduction to Computer Programming : You Can Do It!》。这也是Bjarne的推荐。Francis Glassborow是ACCU主席，多年来他对几乎每一本C++经典名著评头论足，他自己的这一本自然会引起C++社群的极大兴趣。

高效、健壮编程

两年前我在负责一个省级电力调度系统项目时编写了一个网关程序，它从SCADA系统获取电力实时信息。通讯接口采用了不常用的数据库直连方式（这个网关程序一端连接SQL Server 6.5，另一端连接Oralce 8.1.6）。由于实时测点近万，每次将全部取样更新或插入一遍显然是低效的。我在网关程序里建了一个内存库，获取到的数据首先在其中进行比较，然后决定是否更新物理数据库（同时还做了别的更复杂的事情……），从而在效率和资源占用两方面达到了预期效果。

这个程序一直运行得很好，但在离开现场之后的某一天，系统管理员打来电话，说大概因为网络故障等原因，有时这个网关程序会崩溃掉 — 它自己崩掉也就罢了，问题是它还会把Windows 2000 Advanced Server搞成“蓝屏”！坦白地说，我还从来没看过哪个非蓄意的程序有这个“能耐”。由于当时正忙于另外一个大项目，无法去现场调试，最后只有凭经验对内存库代码小心翼翼地封装以异常处理代码（同时也做了一些别的修改……）。这样，虽然没有彻底解决问题，但程序终究不再死得那么难看了。

在这儿讲这么一段花絮有什么意思呢（当初为那个可怕的bug朝思暮想时我可不认为这是一个“花絮”）？我想说的是，对于任何软件而言，离开强健，效率也就无从谈起。而对于C++程序员来说，也许编写一个高效的程序并不难，但要编写一个需要7 ⅹ 24小时持续运行的服务端软件就不是那么容易了，需要考虑许多因素，有时这些因素甚至远远超出C++语言和开发工具的本身。作为一名开发实际项目软件的程序员，并非非得自己碰钉子才能积累经验，只要我们足够虚心，别人的经验往往都是我们很好的借鉴。鉴于此，我推荐以下几本书供你选读，它们可以让你从强健和效率两方面受益（当然了，它们涵盖的内容远不限于异常处理J）。

Scott Meyers, Effective C++: 50 Specific Ways to Improve Your Programs and Design (2nd Edition)
Scott Meyers, More Effective C++: 35 New Ways to Improve Your Programs and Designs
《Effective C++中文版》，华中科技大学出版社
《More Effective C++中文版》，中国电力出版社
《Effective C++（影印版）》，中国电力出版社

如果说《Effective C++》主要讨论C++中一些相对基础的概念和技巧的话，那么《More Effective C++》则着重探讨了包括异常处理在内的一系列高级技术。与前者相比，后者具有两大主要区别：其一，它包含很多时新的标准C++的内容；第二，它讨论的主题倾向于“战略化”而非“战术化”，并且讨论得更深入、更彻底。尤其是对虚析构函数、智能指针、引用计数以及代理类（proxy classe）等技术和模式论述的深入程度，让人很难想象是出现于这样的一本小书之中。

游刃有余的技术，高超的写作技巧，Scott无疑是世界上最优秀的C++技术作家之一。在简洁、清晰、易读等方面，这两本书都卓尔不群。总之，Scott提供的这85个可以改善编程技术和设计思维的方法，都是中、高级C++程序员必备的技能。我强烈推荐这两本书（实际上还有一本，稍后就会看到）。

Herb Sutter, Exceptional C++: 47 Engineering Puzzles, Programming Problems, and Solutions
Herb Sutter, More Exceptional C++: 40 New Engineering Puzzles, Programming Problems, and Solutions
《Exceptional C++中文版》，中国电力出版社
《More Exceptional C++中文版》，华中科技大学出版社

你自认为是一名C++语言专家吗？读一读ISO C++标准委员会秘书长的这两本书再回答。在这两本书中，Herb采用了“问答”的方式指导你学习C++语言特性。对于每一个专题，Herb首先合理地设想出你的疑问和困惑，接着又猜测出你十有八九是错误的解答，然后给你以指点并提出最佳解决方案，最后还归纳出解决类似问题的普适性原则。

这两本书是典型的深究C++语言细节的著作，很薄，但内容密集，远远超过Scott的那两本书，读起来很费脑筋 — 我个人认为它们要比Scott的书难懂得多。若要研习这薄薄的两本书所包含的知识，至少需要花费数月的时间！（在Scott的荐序中，他坦陈不止一次陷入GotW问题的陷阱，你应该知道这意味着什么）对于语言细节的深究有什么好处呢？尽管在大多数情况下，我们不必关心C++代码幕后的动作，然而当我们不得不关心时，这两本书可以为我们提供很好的线索，因为它们揭示了C++语言中微妙而又至关重要的东西。

Stephen C. Dewhurst, C++ Gotchas: Avoiding Common Problems in Coding and Design
《C++程序设计陷阱》，中国青年出版社

Stephen的理论素养和实践经验注定这是一本值得一读的好书。Stephen曾经是贝尔实验室中第一批C++使用者。他已经使用C++成功解决了包括编译器、证券交易、电子商务以及嵌入式系统等领域中的问题。本书汇集了作者来自开发一线的99条编程真知灼见，洞悉它们，你可以避免几乎所有常见的C++设计和编程问题。

我甚至认为，对于C++编程菜鸟而言，阅读这本书会比阅读Scott和Herb的书更能轻松而立竿见影地获得更大的提高。我个人很喜欢这本书的写作风格 — Stephen的许多观点看似极端却无可辩驳。当然了，这种自信（以及冷幽默）来自于作者深厚的技术素养，而非自大的偏执。

除了上面推荐的书籍外，Dov Bulka和 David Mayhew合著的《Efficient C++: Performance Programming Techniques》（《提高C++性能的编程技术》，清华大学出版社）也值得一看。这本超薄小书聚焦于高性能C++应用程序开发。两位作者都是IBM软件专家，都工作于对性能要求极高的系统构建领域，本书是他们的经验之谈。也有人不喜欢这本书，因为它花了不少的篇幅讲述和C++无关的东西，我却恰恰因为这一点而对这本书产生好感，正是这些东西让我开阔了眼界。

模板和泛型编程

模板和基于模板的泛型编程无疑是当今发展最活跃的C++程序设计技术。模板的第一个革命性的应用是STL，它将模板技术在泛型容器和算法领域的运用展现得淋漓尽致，而Boost、Loki等现代程序库则将模板技术的潜能不断发挥到极致。在模板和泛型编程领域，我推荐以下两本重量级著作：

David Vandevoorde, Nicolai M. Josuttis, C++ Templates: The Complete Guide
《C++ Templates全览（繁体版）》，台湾碁峰资讯股份有限公司
《C++ Templates全览（简体版）》，人民邮电出版社

有一种老套的赞美一本书的手法，大致是“没有看过这本书，你就怎么怎么地”，这里面往往夸张的成分居多。不过，倘若说“没有看过《C++ Templates: The Complete Guide》，你就不可能精通C++模板编程”，那么这个论断对于世界上绝大多数C++程序员来说是成立的。

这本书填补了C++模板书籍领域由来已久的空白。此前，上有《Modern C++ Design》这样的专注于模板高级编程技术和泛型模式的著作，下有《The C++ Standard Library》这样的针对特定模板框架和组件的使用指南。然而，假如对模板机制缺乏深入的理解，你就很难“上下”自如。鉴于此，我向每一位渴望透彻理解C++模板技术的朋友推荐这本书。

这本书在内地、台湾各有一个译本，但出自不同的译者之手。当你看到这篇文章时，两个译本应该都已经上市，对于读者来说当然也就多了一种选择。侯捷先生个人网站上开放了繁体译本大部分章节，不妨先睹为快。

Andrei Alexandrescu, Modern C++ Design: Generic Programming and Design Patterns Applied
《C++设计新思维：泛型编程与设计模式之应用》，华中科技大学出版社
《C++设计新思维（影印版）》，中国电力出版社

你自认为是C++模板编程高手吗？请看过这本书再回答J 这是一本出自天才之手令人敬畏的杰作。泛型模式，无限延伸你的视野，足以挑战任何一名C++程序员的思维极限。

这本书共分为两大部分，第一部分讨论了 Loki程序库采用的基础技术以及一些高级语言特性，包括基于策略的类设计、模板局部特化、编译期断言、Typelist以及小型对象分配技术等。第二部分则着重介绍了Loki中的重要组件和泛型模式技术，包括泛化仿函数（Generalization Functor）、单件（Singleton）、智能指针、对象工厂（Object Factory）、抽象工厂（Abstract Factory）、访问者（Visitor）以及多方法（Multimethods）等。每一种技术都让人大开眼界，叹为观止。

在C++的学习方面，过犹不及往往成了不求甚解的借口。然而，面向对象并非C++的全部，模板和泛型编程亦占半壁江山。对于“严肃”的C++程序员而言，及时跟进这项早经例证的成功技术，不失为明智之举。

结语

这些著作是如此大名鼎鼎，也许根本不缺我一个推荐。然而，纵然C++程序员队伍的发展壮大速度不像其他更时髦的语言那样迅速，新人进总是多于旧人出。除了热忱地欢迎新人，我个人认为到了对C++书籍进行“盘点”的时候了，并且希望这样的“盘点”有益于感兴趣的读者。请保持耐心和宽厚。在下篇中，我将继续介绍标准库、网络编程以及其他方面的C++好书。有好书相伴，这个冬天不会冷

一、STL简介

STL（Standard Template Library，标准模板库)是惠普实验室开发的一系列软件的统称。它是由Alexander Stepanov、Meng Lee和David R Musser在惠普实验室工作时所开发出来的。现在虽说它主要出现在C++中，但在被引入C++之前该技术就已经存在了很长的一段时间。

STL的代码从广义上讲分为三类：algorithm（算法）、container（容器）和iterator（迭代器），几乎所有的代码都采用了模板类和模版函数的方式，这相比于传统的由函数和类组成的库来说提供了更好的代码重用机会。在C++标准中，STL被组织为下面的13个头文件：<algorithm>、<deque>、<functional>、<iterator>、<vector>、<list>、<map>、<memory>、<numeric>、<queue>、<set>、<stack>和<utility>。以下笔者就简单介绍一下STL各个部分的主要特点。

二、算法

大家都能取得的一个共识是函数库对数据类型的选择对其可重用性起着至关重要的作用。举例来说，一个求方根的函数，在使用浮点数作为其参数类型的情况下的可重用性肯定比使用整型作为它的参数类性要高。而C++通过模板的机制允许推迟对某些类型的选择，直到真正想使用模板或者说对模板进行特化的时候，STL就利用了这一点提供了相当多的有用算法。它是在一个有效的框架中完成这些算法的——你可以将所有的类型划分为少数的几类，然后就可以在模版的参数中使用一种类型替换掉同一种类中的其他类型。

STL提供了大约100个实现算法的模版函数，比如算法for_each将为指定序列中的每一个元素调用指定的函数，stable_sort以你所指定的规则对序列进行稳定性排序等等。这样一来，只要我们熟悉了STL之后，许多代码可以被大大的化简，只需要通过调用一两个算法模板，就可以完成所需要的功能并大大地提升效率。

算法部分主要由头文件<algorithm>，<numeric>和<functional>组成。<algorithm>是所有STL头文件中最大的一个（尽管它很好理解），它是由一大堆模版函数组成的，可以认为每个函数在很大程度上都是独立的，其中常用到的功能范围涉及到比较、交换、查找、遍历操作、复制、修改、移除、反转、排序、合并等等。<numeric>体积很小，只包括几个在序列上面进行简单数学运算的模板函数，包括加法和乘法在序列上的一些操作。<functional>中则定义了一些模板类，用以声明函数对象。

三、容器

在实际的开发过程中，数据结构本身的重要性不会逊于操作于数据结构的算法的重要性，当程序中存在着对时间要求很高的部分时，数据结构的选择就显得更加重要。

经典的数据结构数量有限，但是我们常常重复着一些为了实现向量、链表等结构而编写的代码，这些代码都十分相似，只是为了适应不同数据的变化而在细节上有所出入。STL容器就为我们提供了这样的方便，它允许我们重复利用已有的实现构造自己的特定类型下的数据结构，通过设置一些模版类，STL容器对最常用的数据结构提供了支持，这些模板的参数允许我们指定容器中元素的数据类型，可以将我们许多重复而乏味的工作简化。

容器部分主要由头文件<vector>,<list>,<deque>,<set>,<map>,<stack>和<queue>组成。对于常用的一些容器和容器适配器（可以看作由其它容器实现的容器），可以通过下表总结一下它们和相应头文件的对应关系。

四、迭代器

下面要说的迭代器从作用上来说是最基本的部分，可是理解起来比前两者都要费力一些（至少笔者是这样）。软件设计有一个基本原则，所有的问题都可以通过引进一个间接层来简化，这种简化在STL中就是用迭代器来完成的。概括来说，迭代器在STL中用来将算法和容器联系起来，起着一种黏和剂的作用。几乎STL提供的所有算法都是通过迭代器存取元素序列进行工作的，每一个容器都定义了其本身所专有的迭代器，用以存取容器中的元素。

迭代器部分主要由头文件<utility>,<iterator>和<memory>组成。<utility>是一个很小的头文件，它包括了贯穿使用在STL中的几个模板的声明，<iterator>中提供了迭代器使用的许多方法，而对于<memory>的描述则十分的困难，它以不同寻常的方式为容器中的元素分配存储空间，同时也为某些算法执行期间产生的临时对象提供机制,<memory>中的主要部分是模板类allocator，它负责产生所有容器中的默认分配器。

五、对初学者学习STL的一点建议

对于之前不太了解STL的读者来说，上面的文字只是十分概括地描述了一下STL的框架，对您理解STL的机制乃至使用STL所起到的帮助微乎甚微，这不光是因为深入STL需要对C++的高级应用有比较全面的了解，更因为STL的三个部分算法、容器和迭代器三部分是互相牵制或者说是紧密结合的。从概念上讲最基础的部分是迭代器，可是直接学习迭代器会遇到许多抽象枯燥和繁琐的细节，然而不真正理解迭代器又是无法直接进入另两部分的学习的（至少对剖析源码来说是这样）。可以说，适应STL处理问题的方法是需要花费一定的时间的，但是以此为代价，STL取得了一种十分可贵的独立性，它通过迭代器能在尽可能少地知道某种数据结构的情况下完成对这一结构的运算，所以下决心钻研STL的朋友们千万不要被一时的困难击倒。其实STL运用的模式相对统一，只要适应了它，从一个STL工具到另一个工具，都不会有什么大的变化。

对于STL的使用，也普遍存在着两种观点。第一种认为STL的最大作用在于充当经典的数据结构和算法教材，因为它的源代码涉及了许多具体实现方面的问题。第二种则认为STL的初衷乃是为了简化设计，避免重复劳动，提高编程效率，因此应该是“应用至上”的，对于源代码则不必深究。笔者则认为分析源代码和应用并不矛盾，通过分析源代码也能提高我们对其应用的理解，当然根据具体的目的也可以有不同的侧重。

最后要说的是，STL是ANSI/ISO C++标准的一部分，所以对于一个可以有多种C++实现的过程，首先考虑的应该是STL提供的模板（高效且可移植性好），其次才是各个厂商各自相应的库（高效但可移植性不好）以及自己去编写代码（可移植性好但低效）。

 };
 template <typename T2>
  void print(T2 a)
 {
  cout<<a;
 };
protected:
private:
};
                         1个好的例子
                           template <typename T>   class A  
                                {      public:
                                                      template <typename T1>               
                                                      A&    operator =(const A<T1> & );
                               }
                               如此 则A 的对象 可以用其他型的对象赋值了
     在使用时才实例化
                                        但是其定义比较骇人
                         template <typename T>
                                     template<typename T1>
                                     A<T>&  A<T>::operator=(const A<T1>& a)
                                   {  ...........................}



6.类模版的特化
      特化1个类模板（所有成员必须特化包括静态类数据成员(vc),但友元模板（1：1）可以
不特化，当作一个显示实参的函数模板处理即可） 或 特化1个模板 成员函数

         模板成员函数特化是定义必须出现在实现文件（cpp)中
       语法为
    void man<int>::f(void)
{
............................
}
      
类特化
 template <>
class man<int>
{
       ......//中所有类型参数以int 替代
};
      
  man<int>::man()
{
......
}

void man<int>::f(void)
{
}
注意  类成员中
   static const 有序类型可以在体内初始化static const int a=10;
                        仅仅static  必须在体外
                                                               static int a;
                                                              int woman::a=10;
   非 特化
   template <typename T>
   int man<T>::size=10;
   特化
   int man<char>::size=10;
7偏特化
   类模板有1个以上模版参数（类型参数，非类型参数）
              某些模版参数 被实际的型和值取代（注意是 取代 ，不是增加，减少）
      如：

//////////////////头文件
       template <typename T1,typename T2,int size>
class wc
{
public:
 wc()
 {
  cout<<"\n int T1,T2, int";
 }
protected:
private:
};
template <typename T,int size>
class  wc<T* ,T,size>
{
public:
 wc()
 {
  cout<<"\n in T *, T ,size";
 }
protected:
private:
};
template <typename T,int size>
class  wc<T* ,float,size>
{
public:
 wc()
 {
  cout<<"\n in T* ,float,size";
 }
protected:
private:
};
template <typename T>
class  wc<T* ,float,80>
{
public:
 wc()
 {
  cout<<"\n in T* ,float,80";
 }
protected:
private:
};
///////头文件
//////main()
wc<int,float,10> wc1;
 wc<int* ,int ,20> wc2;
 wc<int*,float,39> wc3;
wc<int*,float,80>wc4;
///////main() ,在vc 7 上通过
//////main()


8.预设模板参数(只有在类模板中才指定 ，1 .  明确指定 a<int,int>   ,直接定义时 man<>  kkk;2. a<T,T> )
template <typename T,typename T1=float>
class man
{
..........
}

写到这里突然想到
                  class A {
                            virtual void   print();
                              };
                  class B:public A {
                                          virtual void print();
                                          };
B b;
                 A *a =&b;
                a->print();//调用 B的，此时 print()中的this 指针是 B * const,使用B 的接口 ;

9.双重模板参数（很有用）
                template <typename T,typename G =man<T> >
 class baby
 {
 public:
  baby ()
  {
   cout<<"\n in baby";
  }
 protected:
 private:
 };//类型参数可以是 类类型
        
baby<int, man<float> > b;  //ok
////////////////////////
template <typename T,template <typename G> class TT>//可以省略为 template <typename T  ,template<typename>  class  TT>
 class  son
 {
 public:
   TT<T> * a; 
     son()
  {
           a=0;
   cout<<"\n in son";
  }
 protected:
 private:
 };
   son<int, man> b;//则就含有了 man<int > * a;
TT 是模板占位符号，是一个带1个类型参数的类模板，如果其有默认模板参数 则忽略掉  
所以 GG若带默认 的模板 应该如下
            template <typename T, template <typename T2, typename= man<T2>  > class GG>
class son
{
}

/////////   类模板类型参数 同时还可以是 类模板

10. 字符串常量在模板中的注意事项

           char * a="hi ,friend ";///"hi, friend"  文字常量 是 const char [10] 类型  左值转换到 const char *
限定转换到 char *,
                template <typename T〉
      ostream& operator <<(ostream & os, const T & b)；//注意只有const 才能接受临时变量

             cout<<"hi,friend";  
              cout<<"bad";
/////2个不同的模板实例
   typeid(变量).name();///直接打印出变量类型
写到这，闲扯下：
    栈区，堆区，全局（静态）区，文字常量，代码区，5个大区，这个是我听说的
////////////////////////////////////////////////
11.模板的编译模型
     在实例化点必须能找到定义//原则
                           只能使用包含模式了，
a..h. cpp 在 .h最后一行包含进 cpp
b. 全部在h 或 cpp

                     分离模式,目前支持的export 关键字i的编译器很少（vc.net 不支持）

12.
函数指针类型也能做模板类型参数

bool  minn( int  a, int  b)
{
      return  a < b;
 }

 template  < typename T1,typename T2 >
     const  T1 &   mymin( const  T1 &  t1,  const  T1 &  t2, T2 t3 )
  {
      return  t3(t1,t2) ? t1:t2;
 }
void  main()
{
cout << mymin( 2 , 3 ,minn);
}

13.
模板参数可以是个类模板  
template <typename T>
class a
{
};
a< vector <int> >;


template <typename T, typename T2,template <typename T,typename T2> class con  >
void add(con<T,T2>,con<T,T2>)
{
 cout<<"ok";
}

add(a,b)//特殊在于 需要推导,vc 7 可以从  类模板中推导出参数类型

template <typename T,template <typename T2,typename T3> class con >
class ggoo
{
public:
 con<T,T> a;
con<int,int> b;

protected:
private:
};

ggoo<int,double, b> kk;//b<int,double>, con 的模板参数可以任意