在C++中封装的概念是把一个对象的外观接口同实际工作方式（实现）分离开来，但是C++的封装是不完全的，编译器必须知道一个对象的所有部分的声明，以便创建和管理它。我们可以想象一种只需声明一个对象的公共接口部分的编程语言，而将私有的实现部分隐藏起来。C + +在编译期间要尽可能多地做静态类型检查。这意味着尽早捕获错误，也意味着程序具有更高的效率。然而这对私有的实现部分来说带来两个影响：一是即使程序员不能轻易地访问实现部分，但他可以看到它；二是造成一些不必要的重复编译。

            然而C++并没有将这个原则应用到二进制层次上，这是因为C++的类既是描述了一个接口同时也描述了实现的过程,示例如下：

class CMyString
{
private:
 const int m_cch;
  char *m_psz;
public:
  CMyString(const char *psz);
  ~CMyString();
  int Length() const;
  int Index(const char *psz) const;
}

CMyStirng对外过多的暴露了内存布局实现的细节，这些信息过度的依赖于这些成员变量的大小和顺序，从而导致了客户过度依赖于可执行代码之间的二进制耦合关系，这样的接口不利于跨语言跨平台的软件开发和移植。

1.1.1      Handle-Body模式

       解决这个问题的技术有一种叫句柄类（ handle classes）。有关实现的任何东西都消失了，只剩一个单一的指针“m_pThis”。该指针指向一个结构，该结构的定义与其所有的成员函数的定义都出现在实现文件中。这样，只要接口部分不改变，头文件就不需变动。而实现部分可以按需要任意更动，完成后只要对实现文件进行重新编译，然后再连接到项目中。

       下面是这项技术的简单例子。头文件中只包含公共的接口和一个简单的没有完全指定的类指针。

class CMyStringHandle
{
private:
  class CMyString；
  CMyString *m_pThis;
public:
  CMyStringHandle (const char *psz);
  ~ CMyStringHandle ();
  int Length() const;
  int Index(const char *psz) const;
}；

CMyStringHandle:: CMyStringHandle(const char *psz)
:m_pThis(new CMyString(psz));
{
}

CMyStringHandle::~ CMyStringHandle()
{
   delete m_pThis;
}

int CMyStringHandle::Length()
{
  return m_pThis->Length();
}

int CMyStringHandle::Index(const char *psz)
{
 return m_pThis->Index(psz);
}

    这是所有客户程序员都能看到的。
            class CMyString；

是一个没有完全指定的类型说明或类声明（一个类的定义包含类的主体）。它告诉编译器，CMyString是一个结构的名字，但没有提供有关该结构的任何东西。这对产生一个指向结构的指针来说已经足够了。但我们在提供一个结构的主体部分之前不能创建一个对象。在这种技术里，包含具体实现的结构主体被隐藏在实现文件中。

            在设计模式中，这就叫做Handle-Body 模式，Handle-Body只含有一个实体指针，服务的数据成员永远被封闭在服务系统中。

Handle-Body的布局结构永远不会随着实现类数据成员的加入或者删除或者修改而导致Handle-Body的修改，即Handle-Body协议不依赖于C++实现类的任何细节。这就有效的对用户的编译器隐藏了这些细节，用户在使用对这项技术时候，Handle-Body 接口成了它唯一的入口。

然而Handle-Body模式也有自己的弱点：

1、接口类必须把每一个方法调用显示的传递给实现类，这在一个只有一个构造和一个析构的类来说显然不构成负担，但是如果一个庞大的类库，它有上百上千个方法时候，光是编写这些方法传递就有可能非常冗长，这也增加了出错的可能性。

2、对于关注于性能的应用每一个方法都得有两层的函数调用，嵌套的开销也不理想

3、由于句柄的存在，依然存在编译连接器兼容性问题。

1.1.2        抽象接口

            使用了“接口与实现的分离”技术的 Handle-Body 解决了编译器/链接器的大部分问题，而C++面向对象编程中的抽象接口同样是运用了“接口与实现分离”的思想，而采用抽象接口对于解决这类问题是一个极其完美的解决方案。

1、抽象接口的语言描述：

            class IMyString

            {

              virtual int Length() const = 0; //这表示是一个纯虚函数，具有纯虚函数的接口

              virtual int Index(const char *psz) const = 0;

            }；

2、抽象接口的内存结构：

        抽象接口采用虚函数表来调用成员方法。 

3、   抽象接口的实现代码：

              接口：

            class IMyString

            {

              virtual int Length() const = 0; //这表示是一个纯虚函数，具有纯虚函数的接口

              virtual int Index(const char *psz) const = 0;

            }；

             实现：

            class CMyString：public IMyString

            {

            private:

             const int m_cch;

              char *m_psz;

            public:

              CMyString(const char *psz);

              virtual ~CMyString();

              int Length() const;

              int Index(const char *psz) const;

            }

            从上面采用抽象接口的实例来看，抽象接口解决了Handle-Body所遗留下来的全部缺陷。

抽象接口的一个典型应用：

            抽象工厂（AbstractFactroy）

1.2       多继承与菱形缺陷、this跳转等

多重继承是C++语言独有的继承方式，其它几乎所有语言都秉承了单一继承的思想。这是因为多重继承致命的缺陷导致的：

1.2.1        菱形缺陷

当继承基类时，在派生类中就获得了基类所有的数据成员副本。假如类B 从A1和A2两个类多重继承而来，这样B类就包含A1、A2类的数据成员副本。

考虑如果A1、A2都从某基类派生，该基类称为Base，现在继承关系将出现菱形继承关系。

class Base{… … }；

class A1 :public Base {… … }；

class A2 :public Base {… … }；

class B :public A1,public A2 {… … }；

那么A1、A2都具有Base的副本。这样B就包含了Base的两个副本，副本发生了重叠，不但增加了存储空间，同时也引入了二义性。这就是菱形缺陷，菱形缺陷的两个缺陷：

1、子对象重叠

2、向上映射的二义性。

菱形缺陷的其中一种解决办法是使用虚拟继承。

在C++世界里最广泛的使用虚拟继承解决菱形缺陷的应用便是标准C++的输入/输出iostream；

1.2.2        多重接口与方法名冲突问题（Siamese twins）

       对继承而来的虚函数改写很容易，但是如果是在改写一个“在两个基类都有相同原型”的虚函数情况就不那么容易了。

       提出问题：

       假设汽车最大速度的接口为ICar，潜艇最大速度的接口为 IBoat，有一个两栖类的交通工具它可以奔跑在马路上，也可以航行在大海中，那么它就同时拥有ICar、IBoat两种交通工具的最大速度特性，我们定义它的接口为ICarBoat；

       class ICar

       {

             virtual int GetMaxSpeed（）= 0；

       }；

       class IBoat

       {

      virtual int GetMaxSpeed（）= 0；

       }；

   我们先对ICarBoat的接口做一个尝试：

       class CCarBoat

       {

              virtual int GetMaxSpeed（）；//既完成ICar的GetMaxSpeed（）接口方法又                                     //完成IBoat的接口方法？显然不能够

       };

解决问题：

       显然上面这个尝试根本就无法成功，只用一个实现方法，怎么能够求出这个ICarBoat交通工具奔跑在马路上的最高时速，同时也能够求出航行在大海上的最大航行速度呢。

       上面这一问题矛盾就在一一个方法，却需要两个答案。看来ICarBoat要返回两个答案就必须有两个方法了，我们假设一个方法是求在陆地上奔跑的速度，名称为GetCarMaxSpeed（）；另一个方法是求在大海上航行的最大速度，名称为GetBoatMaxSpeed（）；那这两个方法又怎么和GetMaxSpeed（）接口方法联系起来呢；

       幸运的是，我们找到了解决办法，而且解决办法有很多种，下面介绍一下继承法。

       class IXCar :public ICar

       {

             virtual int GetMaxSpeed（）

              {

                     GetCarMaxSpeed();

              }

              virtual int GetCarMaxSpeed（） = 0;

       }；

       class IXBoat:public IBoat

       {

              virtual int GetMaxSpeed（）

              {

                     GetBoatMaxSpeed();

              }

              virtual int GetBoatMaxSpeed（） = 0;

       }；

       classCCarBoat: public IXCar , public IXBoat

       {

              virtual int GetCarMaxSpeed（）

              {

                     … …

              }

              virtual int GetBoatMaxSpeed（）

              {

                     … …

              }

       };

1.2.3        this跳转

this跳转是指的“对象同一性”问题。

      在单一继承的世界内，无论继承关系怎么复杂，针对于同一对象，无论它的子类或者父类的this指针永远相等。即如果 B从A继承，那么 对于一个已经实例化B类的对象 bObject，永远有（B*）&bObject ==(A*)&bObject 成立。

      但是在多继承的世界内，上面的等式就不能恒成立，对象的同一性受到了挑战。

      特别的是，在多继承世界内如果菱形关系存在情况下，如果对于已经实例化B类的对象bObject; （Base*）（A1*）&bObject != （Base*）（A2*）&bObject 成立，当这种事情发生的时候我们就只能特殊处理了。这种情况在COM应用中处处都会发生。

1.3       C++多态的两种多态形式和区别

     C++有两种多态多态形式：

1、编译时刻多态，编译时刻多态依靠函数重载或者模板实现

2、运行时刻多态。运行时刻多态依靠需函数虚接口实现

　　但如果真正到了产生可执行代码阶段，无论是c，c++,还是pascal，大家都一样，你认为c和c++编译器产生的机器代码会有所不同吗，你认为c++产生的机器代码会有访问限制吗？那么你错了。什么const，private，统统没有(const变量或许会放入只读数据段)，它不会再给你任何的限制，你可以利用一切内存修改工具或者是自己写一个程序对某一进程空间的某一变量进行修改，不管它在你的印象中是 private，还是public，对于此时的你来说都一样，想怎样便怎样。

　　另外，你也不要为c++所提供的什么晚期捆绑等机制大呼神奇，它也仅仅是在所产生的代码中多加了几条而已，它远没有你想象的那么智能，所有的工作都是编译器帮你完成，真正到了执行的时候，计算机会完全按照编译器产生的代码一丝不苟的执行。

　　(以下的反汇编代码均来自visial c++ 7.0)

　　一.让我们从变量开始-----并非你想象的那么简单

　　变量是什么，变量就是一个在程序执行过程中可以改变的量。换一个角度，变量是一块内存区域的名字，它就代表这块内存区域，当我们对变量进行修改的时候，会引起内存区域中内容的改变。但是你若是学习过汇编或是计算机组成原理，那么你就会清楚对于一块内存区域来说，根本就不存在什么名字，它所仅有的标志就是他的地址，因此我们若想修改一块内存区域的内容，只有知道他的地址方能实现。看来所谓的变量一说只不过是编译器给我们进行的一种抽象，让我们不必去了解更多的细节，降低我们的思维跨度而已。例如下面这条语句：

　　int a=10;

　　按照我们的思维习惯来讲，就是“存在一个变量a，它的值是10”，一切都显得那么的自然。我们不必去在乎什么所谓的地址以及其他的一些细节。然而在这条语句的底层实现中，a已经不能算是一个变量了，它仅仅是一个标记，代表一个地址的标记：

　　mov dword ptr[a],0Ah;

　　怎么样，这条语句不像上面那条易于接受吧，因为它需要了解更多的细节，你几乎不能得到编译器的任何帮助，一切思维上的跨越必须由你自己完成。这条语句应该解释为“把10写入以a为地址的内存区域”。你说什么？a有些像指针？对，的确像，但还不是，只不过他们的过程似乎是类似的。这里所说的跨越实际上就是从一个现实问题到具体地址以及内存区域的跨越。

　　二.引用：你可以拥有引用，但编译器仅拥有指针(地址)

　　看过了第一条，你一定对编译器的工作有了一定的了解，实际上编译器就是程序员与底层之间的一个转换层，它把一个高级语言代码转换为低级语言代码，一个编译器完成的转换跨度越大，那么它也就会越复杂，因为程序员的工作都由他代为完成了。C++编译器必然比汇编编译器复杂就是这个道理。如果我问你引用和指针是一样的吗？你或许会说当然不一样了，指针容易产生不安全的因素，引用却不会，真的不会吗？我们来看下面这段代码：

　　int *e=new int(10);

　　int &f=*e;

　　delete e;

　　f=30;

　　你认为上面这段代码怎么样，我感觉就不很安全，它和指针有相同的隐患。因为它所引用的内存区域就不合法。

　　我个人认为，所谓的引用其实就是一种指针，只不过二者的接口并不相同，引用的接口有一定的限制。指针可以一对多，而引用却只能一对一，即&refer不能被改变，但却并不能说一对一就是安全的，只不过危险的系数降低罢了。引用比指针更容易控制。

　　Ok, 下面来说说指针，曾经有过汇编经验的人一定会说，恩，指针的某些地方有些像汇编，尤其是那个“*”，怎么就那么像汇编中的“[]”啊。的确，它也涵盖了一个寻址的过程。看来指针的确是个比较低级的东西。然而引用却并不那么直接，虽然程序员用起来方便安全了许多。但是你要清楚，只有你可以拥有引用，编译器可没有这个工具，计算机并不认识这个东西。因此，它的底层机制实际上是和指针一样的。不要相信只有一块内存拷贝，不要认为引用可以为你节省一个指针的空间，因为这一切不会发生，编译器还是会把引用解释为指针。不管你相不相信，请看下面这段代码：

　　int& b=a;

　　lea eax,[a];

　　mov dword ptr[b],eax;把a的地址赋给地址为b的一块内存

　　b=50;

　　mov eax,dword ptr[b];

　　mov dword ptr[eax],32h;

　　int *d=&a;

　　lea eax,[a];

　　mov dword ptr[d],eax

　　*d=60;

　　mov eax,dword ptr[d]

　　mov dword ptr[eax],3ch;

　　以上的代码均来自具体的编译器，怎么样，相信了吧，好，让我再来做一个或许不怎么恰当的比拟，你一定编过有关线性表和栈的程序吧，线性表是一个非常灵活的数据结构，在他上面有许多的操作，然而栈呢，它是一个限制性操作的线性表，它的底层操作实际上是由线性表操作实现的。就好比stack与vector的关系，因此指针和引用的关系就好比线性表和栈的关系，引用也就是受限的指针，它对外的接口和指针虽然并不一样，但底层是相同的。

　　下面再来看看引用的一个重要用途，作为函数的参数传递的时候是怎样的情形：

　　void swapr(int &a, int &b)；

　　void swapr(int* a, int *b)；

　　int a=10;

　　int b=20;

　　swapr(a, b);

　　lea eax,[a];

　　push eax; //把a的地址压入堆栈

　　lea ecx,[b];

　　push ecx;

　　call swapr;

　　swapr(&a, &b);

　　lea eax,[a];

　　push eax;

　　lea ecx,[b];

　　push ecx;

　　call swapr;

　　怎么样，用引用和指针传递参数无论是在效率上还是在空间上都是完全一样的，如果妄想不传入地址就修改实参的值，简直就是天方夜谭，这就说明引用的本质就是指针。毕竟它们的行为都太相似了，如果不是这样，你还有什么方法去实现引用吗？记住，引用只不过是编译器为你提供的一个有用且安全的工具，对于机器代码可无法表示它，它把指针一对多的缺点去除，禁止了你的不安全的操作。但回到问题的本源，他们没有任何区别。

软件工程

    一般认为，使用Java或C#的开发成本比C++低。但是，如果你能够充分分析C++和这些语言的差别，会发现这句话的成立是有条件的。这个条件就是：软件规模和复杂度都比较小。如果不超过3万行有效代码（不包括生成器产生的代码），这句话基本上还能成立。否则，随着代码量和复杂度的增加，C++的优势将会越来越明显。
    造成这种差别的就是C++的软件工程性。在Java和C#大谈软件工程的时候，C++实际上已经悄悄地将软件工程性提升到一个前所未有的高度。这一点被多数人忽视，并且被大公司竭力掩盖。
    语言在软件工程上的好坏，依赖于语言的抽象能力。从面向过程到面向对象，语言的抽象能力有了一个质的飞跃。但在实践中，人们发现面向对象无法解决所有软件工程中的问题。于是，精英们逐步引入、并拓展泛型编程，解决更高层次的软件工程问题。（实际上，面向对象和泛型编程的起源都可以追溯到1967年，但由于泛型编程更抽象，所以应用远远落后于面向对象）。
    一个偶然的机会，我突发奇想，试图将货币强类型化，使得货币类型可以采用普通的算术表达式计算，而无需关心汇率换算的问题。具体的内容我已经写成文章，放在blog里：http://blog.csdn.net/longshanks/archive/2007/05/30/1631391.aspx。（CSDN的论坛似乎对大文章有些消化不良）。下面我只是简单地描述一下问题，重点还在探讨语言能力间的差异。
    当时我面临的问题是：假设有四种货币：RMB、USD、UKP、JPD。我希望能够这样计算他们：
RMB rmb_(1000);
USD usd_;
UKP ukp_;
JPD jpd_(2000);

usd_=rmb_;//赋值操作，隐含了汇率转换。usd_实际值应该是1000/7.68=130.21
rmb_=rmb_*2.5;//单价乘上数量。
ukp_=usd_*3.7;//单价乘上数量，赋值给英镑。隐含汇率转换。
double n=jpd_/(usd_-ukp_);//利用差价计算数量。三种货币参与，隐含汇率转换。
而传统上，我们通常用一个double或者currency类型表示所有货币。于是，当不同币种参与运算时，必须进行显式的汇率转换：
double rmb_(100), usd_(0), ukp_(0), jpn_(2000);

usd_=rmb_*usd_rmb_rate;
ukp_=(usd_*usd_ukp_rate)*3.7;
double n=jpd_/((usd_*usd_jpd_rate)-(ukp_*ukp_jpd_rate))
很显然，强类型化后，代码简洁的多。并且可以利用重载或特化，直接给出与货币相关的辅助信息，如货币符号等（这点我没有做，但加上也不复杂）。
在C++中，我利用模板、操作符重载，以及操作符函数模板等技术，很快开发出这个货币体系：
template<int CurrType>
class Currency
{
public:
   Currency<CurrType>& operator=(count Currency<ct2>& v) {
…
   }
public:
   double _val;
…
};
template<int ty, int tp>
inline bool operator==(currency<ty>& c1, const currency<tp>& c2) {
…
}
 
template<int ty, int tp>
inline currency<ty>& operator+=(currency<ty>& c1, const currency<tp>& c2) {
…
}
template<int ty, int tp>
inline currency<ty> operator+(currency<ty>& c1, const currency<tp>& c2) {
…
}
…
总共不超过200行代码。（当然，一个工业强度的货币体系，需要更多的辅助类、函数等等。但基本上不会超过500行代码）。如果我需要一种货币，就先为其指定一个int类型的常量值，然后typedef一下即可：
const int CT_RMB=0;//也可以用enum
typedef Currency<CT_RMB>RMB;
const int CT_USD=1;
typedef Currency<CT_USD>USD;
const int CT_UKP=2;
typedef Currency<CT_USD>USD;
const int CT_JPD=3;
typedef Currency<CT_USD>USD;
…
每新增一种货币，只需定义一个值，然后typedef即可。而对于核心的Currency<>和操作符重载，无需做丁点改动。
之后，我试图将这个货币体系的代码移植到C#中去。根据试验的结果，我也写了一篇文章（也放在blog里：http://blog.csdn.net/longshanks/archive/2007/05/30/1631476.aspx）。我和一个同事（他是使用C#开发的，对其更熟悉），用了大半个上午，终于完成了这项工作。
令人丧气的事，上来就碰了个钉子：C#不支持=的重载。于是只能用asign<>()泛型函数代替。之后，由于C#的泛型不支持非类型泛型参数，即上面C++代码中的int CurrType模板参数的泛型对等物，以及C#不支持泛型操作符重载，整个货币系统从泛型编程模式退化成了面向对象模式。当然，在我们坚持不懈的努力下，最后终于实现了和C++中一样的代码效果（除了那个赋值操作）：
assign(rmb_, ukp_);
assign(usd_, rmb_*3.7);
…
我知道，有些人会说，既然OOP可以做到，何必用GP呢？GP太复杂了。这里，我已经为这些人准备了一组统计数据：在C#代码中，我实现了3个货币，结果定义了4个类（一个基类，三个货币类）；重载30个算术操作符（和C++一样，实现10个操作符，每个类都得把10个操作符重载一遍）；6个类型转换操作符（从两种货币类到第三货币类的转换操作符）。
这还不是最糟的。当我增加一个货币，货币数变成4个后，数据变成了：5个类；40个算术操作符重载；12个类型转换操作符重载。
当货币数增加到10个后：11个类；100个算术操作符重载；90个类型转换操作符重载。
反观C++的实现，3个货币时：1个类模板；1个赋值操作符重载模板；10个算术操作符重载模板；外加3个const int定义，3个typedef。
10个货币时：1个类模板；1个赋值操作符重载模板；10个算术操作符重载模板；const int定义和typedef分别增加到10个。
也就是说C++版本的代码随着货币的增加，仅线性增加。而且代码行增加的系数仅是2。请注意，是代码行！不是类、函数，也不是操作符的数量。而C#版本的代码量则会以几何级数增加。几何级数！！！
这些数字的含义，我就不用多说了吧。无论是代码的数量、可维护性、可扩展性C++都远远好于C#版本。更不用说可用性了（那个assign函数用起来有多难看）。
    我知道，有些人还会说：货币太特殊了，在实践中这种情况毕竟少见。没错，货币是比较特殊，但是并没有特殊到独此一家的程度。我曾经做了一个读取脚本中的图形信息，并绘图输出的简单案例，以展示OOP的一些基本概念，用于培训。但如果将其细化，可以开发出一个很不错的脚本绘图引擎。其中，我使用了组合递归、多态和动态链接，以及类工厂等技术。就是那个类工厂，由于我使用了模板，使得类工厂部分的代码减少了2/3，而且没有重复代码，更易维护。关于抽象类工厂的GP优化，Alexandrescu在其《Modren C++ design》中，有更多的案例。同样的技术，还可以推广到业务模型的类系统中，优化类工厂的代码。
如果还不满意，那么就去看看boost。boost的很多库实现了几乎不可想象的功能，比如lambda表达式、BGL的命名参数等等。它为我们很多优化软件代码新思路，很多技术和方法可以促进我们大幅优化代码，降低开发成本。
    最后，如果你认为C#的最大的优势在于.net平台，那我可以告诉你，这个世界上还有一种东西叫C++/CLI，完全可以满足.net的开发，而且更好，足以擦干净.net那肮脏的屁股。不过，这将会是另外一个故事了…

什么是高级C++？

——软件工业化时代的C++价值观
孟岩
《程序员》杂志社

开门见山

主要论点：
    1. C++本质上是一种重“创新”而轻“生产”的语言，到目前为止仍然是主流语言中最适合技术创新的一个；
    2. 1995年之前，整个软件产业处于“创新为王”的阶段，C++是最适合这个阶段的语言，这是C++红极一时的大背景和根本原因。
    3. 1995年发生了一系列影响深远的事件，软件产业整体上转向工业化，为了支持工业化，创新的重点由技术创新转向体系创新。然而C++没有能够迅速适应这一变化。
    4. 今天，C++应当准确定位，弥补不足，有针对性地发展，它将仍然是最重要的几种工业级语言之一。

从一本书说起
James Coplien，Advanced C++ Programming Styles and Idioms, Addison Wesley, 1991
—— 市面上唯一一本名副其实的“高级”C++书（Scott Meyers）
 ●面向对象特性的运用和把握
 ●面向对象的程序风格
 ●动态特征的运用和超越
 ●符号语言模拟
 ●设计模式

    这本书代表了当时专家们对于“高级C++”的理解，换句话说代表了当时C++社群的一个审美价值取向。我们看到了什么？技术、技巧、风格、模式，但没有与工程相关的东西。更有意思的事情是，这本书的中文版12年后被剽窃出版，此时书中对于C++面向对象能力发挥到了我当时没有想到的程度。这说明即使在template被广泛应用之前，C++语言的技巧性就达到了如此的高度。然而耐人寻味的是，书中最高深的技巧从来就没有在C++实践中流行过。

另一本书...
Scott Meyers, Effective C++ ，1991年第1版，1998年第二版，2005年第三版。
 ●来自教学经验
 ●最初想开发一个代码扫描工具
 ●包含实际工程建议
 ●历史上最重要的C++著作之一

    这本书出版的同时，还有一本在C++历史上影响更大的书问世——Scott Meyers的Effective C++。这本书并没有过多地探索语言技巧，而是探讨实践中应当遵循的规则，或者换句话说，探讨怎样在应用这种语言的同时保持软件的质量，提高开发效率。这本书的内容被整个C++社群熟知并吸收，至今仍在翻新，影响着更多的人。

还是在1991年...
 ●“按照1991年3月C++程序员增长的速度计算，到1996年5月，全世界每一个人都将成为C++程序员。此后我们将不得不教外星人学习C++。”
 ●问题：当时人们为什么如此疯狂地学习一种新语言？
    答案很有趣：大部分人是盲从。但他们所追随的人并非等闲之辈，几乎所有在AT&T Bell Labs、Sun、Borland、IBM、Microsoft的C语言大师都转向C++（Brain Kernighan，Jon Bentley，Peter van der Linden）。而这些人转向C++，不是因为他们知道Effective C++，而是因为他们知道Advanced C++。什么意思呢？就是说人们转向C++，是因为C++充满了令人兴奋的新技巧和未知的创新空间。

1991年...
 ●5000行C代码可以写一个完整的应用程序，获得数万$的回报；
 ●一个TSR式的Help程序可以以shareware的方式通过磁盘发行，开发者银行户头里会收到大量汇款；
 ●John Carmark和Michael Abrash正在各自擅长的方向上不断创新。Doom发行后，id获得收入一度超过微软销售额。

C++历史选择中“创新”压倒“生产”
“相信程序员”；
Be an enable language;
Zero overhead；
STL投票的通过；
偏特化的引入
多继承
Generic/Generated/Meta
IOStream库的设计
Loki/Boost

counted_ptr被否决
可选GC方案被否决
加入类似delegate的对象方法指针提议未引起关注；
virtual关键字
exception机制
缺乏Thread, Network, Regex, DB...等标准库
没有ABI规范
孱弱的RTTI

    并不是事后诸葛亮式的谴责，这就是C++的历史选择，无所谓对错。

    C++重创新轻生产，重技巧轻规范，语言上的创新试验直到1996年ANSI C++标准草案落地才结束。直到2001年Modern C++ Design出版，人们还不断地发现新的语言运用技巧。我们每个人都经历过这个阶段，在实践中发现一个问题，想方设法用尽各种语言技巧来克服它，成则欣喜，败不气馁。我们都曾经相信，C++中一切问题都可以优雅地解决，只有想不到，没有做不到。问题是，从Advanced C++到Modern C++ Design，许许多多令人第一眼看上去无比惊喜的技术，最后在实践中被大范围推广运用的少之又少。C++大师们说这是教育问题，真的是这样吗？

C++社群的价值观
 ●用优雅的技巧解决复杂问题
 ●自己动手，丰衣足食
 ●决不让运行时效率蒙受半点损失
 ●妙者为王
    “管理一群C++程序员就像放牧一群骄傲的猫。”——B. Moo
    “C++程序员是高速公路上穿着短皮茄克，带着墨镜，抽着雪茄，挥舞着铁链的英勇无畏的摩托骑士。” ——VC产品经理

1995年：转折点
 ●Windows 95问世：GUI时代、保护模式操作系统时代、多线程时代的到来，是推动软硬件规模迅速膨胀；
 ●Netscape Navigator vs. Internet Explorer: Web的兴起将人类一下子拖入互联网时代, 个人与企业应用软件网络化；
 ●Java诞生：提供了网络时代、跨平台时代优于C++的企业应用软件开发语言；
 ●COM时代到来
 ●Delphi诞生：创新与工程原则平衡的典范；

1995年：C++全盛时代
 ●C++标准草案接近完成，语言基本稳定；
 ●C++工具大战结束：来自商业竞争的动力消失，MFC获胜；
 ●很多主流软件厂商转向C++，C++开始在大范围内被用于大规模软件开发；
 ●一切迹象表明，软件产业的重点将有创新转向生产。但是：C++社群在指导思想上并没有发生相应的变化。

 
我们的历史失误
 ●C++社群从来没有联合起来支持任何一个跨平台的二进制组件标准（如COM/SOM/CCM）和基础库（如Apache APR、ACE OS Wrapper）；
 ●C++社群从来没有联合起来支持任何一个跨平台的C++虚拟机、解释器、内存检测工具和错误录像工具，也从来没有促成过一个安全的库；
 ●Boost出现于1999-2000年，而在此之前的跨平台C++库都没有获得广泛的支持；
 ●钟情于用C++语法（无论多么复杂和稀奇古怪）完成所有的任务，却丢掉了老祖宗C语言的看家法宝——Little Language；
 ●对于风格争论不休，对于明显的技术进步拒不接受，对于很多后来被证明并不实用的技巧趋之若鹜。

    没有跨平台的基础库，就没有跨平台的动态模块加载机制；
    John Spencer夭折的书《The Art of C Programming》，GoF的Interpreter模式；Little Language实际上具有反映计算机本质的一些东西，现在却成了很少为C++程序员所采用和熟悉的工具。

2005年，C++的现实处境
 ●在系统编程领域仍然强势；
 ●套装软件主流开发语言之一；
 ●嵌入式开发领域进展较快；
 ●游戏引擎开发主力；
 ●科学计算方面略有一席之地
 ●遗留项目的维护；
 ●在企业应用开发领域快速收缩；
 ●Web开发中的影子语言；
 ●从高校主流教学中退潮；
 ●整体水平仍然不高，很多企业急于摆脱；
 ●最致命的：真正了解和熟练掌握C++的人太少；

案例：1. 国外一家公司花高薪聘人，要么能维护目前百万行规模的代码，要么把它转成Java；
          2. IBM Workplace，项目一开始C++/Java并重，之后C++比重越来越小；
          3. 微软与中国电信合作一个项目，客户端软件本来要用C++写，后来赶到产品化周期太长，改用C#，后发先至。 

问题何在
 ●当前的软件产业发展的主要矛盾——各行各业对软件生产标准化、规模化、高质量要求与慢节奏、低效率、低质量的软件开发之间的矛盾。
 ●解决这个矛盾的关键：组件化体系，成熟的软件生产工具和环境，不断的创新精神。
 ●C++在外部环境已经发生根本变化的近十年时间里，没有抓住这个主要矛盾。

重新评估我们的C++价值取向
    重新评估“高级C++”的现实含义：
        - 简洁有效优于惊世骇俗；
        - 开放灵活优于保守固执；
        - 帮助他人优于凸现自己；
        - 领域创新优于卖弄技巧；

 
六个建议
 ●学会与现实和谐共处；
 ●尽快面向不同领域建立跨平台构件标准；
 ●支持各领域已经形成的基础库不断完善；
 ●支持相关工具厂商，迅速完善工具链；
 ●支持动态语言的发展；
 ●面向产业挑战创新发展；

与现实和谐共处
 ●承认C++只适合这个世界的一部分工作，快乐地与其他语言共同协作；
 ●告别妄自尊大和保守傲慢；
 ●尊重其他社群的专业能力和成绩；
 ●坦率承认C++在很多场合并非理想选择；
 ●在C++擅长的领域保持锐意。

跨平台构件标准
 ●C++迈向未来的关键技术步骤；
 ●尽可能支持现有的成熟方案；
 ●在不同尺度的平台上可能需要不同的标准；

支持成熟的基础库
 ●基本组件：STL和Boost（部分）
 ●网络和系统编程：ACE
 ●分布式计算：ICE
 ●GUI：Qt
 ●Windows：MFC/ATL/WTL
 ●科学计算：MTL

完善工具链
 ●C++用的GC；
 ●Code Review工具；
 ●内存错误排查工具；
 ●测试工具；
 ●MDA工具；
 ●文档工具；
 ●持续集成工具；
 ●运行录像工具。

支持动态语言
 ●动态语言是软件技术发展的一个重要方向，几年后会成为主流。
 ●目前几个流行动态语言天生与C/C++具有亲缘关系；
 ●加强对动态语言的友好性，是C++未来发展的一项重要任务；
 ●从这个角度来看待C++/CLI，我们应该持积极态度；
 ●Little Language问题；

迎接产业新挑战
 ●多核CPU带来根本性挑战，C++有责任挺身而出，为其他语言铺平前进道路；
 ●安全性问题，C/C++实际上是给整个产业拖了后腿，对此我们应当充分关注，积极改进；
 ●将STL思想精华发扬光大。