版本：0.1

最后修改：2010-12-10

撰写：李现民

引言

很多游戏都有配套的编辑器，或通用或专用，这样可以方便策划及时设计、修改游戏数据。当一个游戏方案确认实施时，如果需要设计配套编辑器，那么它往往先于游戏本身而设计。出于代码重用和方便维护的需要，大部分核心代码会在游戏客户端与编辑器中同时使用，因此有效提取这部分共用代码并尽量减少与项目其它部分的耦合就成为设计的重点。

关于良好程序架构设计的话题，比如设计模式、领域驱动设计等，相关论著恒河沙数。本文结合实践中遇到的问题，从工具与技术相结合的角度来阐述相关问题的解决方案。

以下假定程序运行环境为VC6+XP。从本文撰写时间看（2010-12-10），VC6无论如何都不是一个好的选择，但限于笔者所在公司环境如此，所以只好将就着来了╮(╯▽╰)╭。

使用宏控制代码生成策略

尽管我们追求代码的可重用性，但实际情况往往并不尽如人意，特别是在与特定于游戏客户端（或编辑器）的功能相结合比较紧密的代码部分。比如UI（界面），游戏客户端中有独立的界面模块，而编辑器界面可能使用MFC制作。即使同一个函数接口，游戏客户端与编辑器所需要的功能也可能是不一样的，这是因为它们拥有各自不同的应用倾向：游戏客户端倾向于使游戏画质更加平滑，而编辑器则需要考虑策划人员快速的编辑修改数据；再比如游戏客户端可能需要网络IO功能，而编辑器则一般不需要。

宏（具体的说，C++中的宏），此时可能是一种比较合适的工具。比如，通过在游戏客户端与编辑器中定义不同的宏变量，可以使游戏客户端专用的网络IO代码在编辑器中根本不生成。

某些情况下可能需要在同一个项目下建立多个configurations（配置），通过定义不同的宏变量以控制生成不同版本的程序，比如：简化版、完整版、内部版等。

宏在VC环境中有大量的应用案例，比如windows.h头文件中定义了大量的宏用于控制不同环境下的代码生成策略。

使用函数控制代码生成策略并信任编译器优化

宏控制的原理是将不需要的代码当作注释直接移除，因此编译器不会去审查该部分代码的正确性。这在某些情况下是必须的，比如编辑器没有网络IO相关的代码接口，因此相关代码必须被清除，否则编辑器项目将无法正确编译。

但宏控制有自己的问题：

1. 宏变量通常定义在Project Settings（工程设置）中，因此不容易记忆或查找；

2. IDE工具通常无法像支持代码一样支持此类宏变量的快速查找，特别是存在多个项目相互引用的复杂工程中（比如Visual Assist X有Find Reference功能，可以快速搜索到所有引用指定变量或函数的代码，但此功能不支持在Project Settings中定义的宏变量）；

3. 编译器无法审查被移除部分代码的正确性，这可能导致一些代码修改同步的问题。

针对这些问题，笔者的解决方案是：宏控制变量只使用一次，用于定义一个简单函数，而该函数返回当前宏控制变量的存在情况，其它原本使用宏控制变量的地方都改为使用这个函数判断。这样间接的将宏变量控制转换为函数控制，从而获得IDE工具支持与编译器代码审查的双重好处。

比如如下代码：

namespace edition
{
#ifdef _EDITOR
inline bool IsEditor() { return true; }
#else
inline bool IsEditor() { return false; }
#endif
}

void Print()
{
if (edition::IsEditor())
{
puts("This is editor");
}
else
{
puts("This is not editor");
}
}

宏变量_EDITOR只使用一次，其余地方都使用edition::IsEditor()区分是编辑器代码还是游戏客户端代码。

请注意，我们并不会有任何的运行期性能损失，虽然看起来并非如此。由于在编译期edition::IsEditor()的值是确定的，因此当打开优化时编译器会移除不可达代码，从而得到与宏控制情况下相同的可执行文件。当然，在Debug版本下（优化关闭）所有的代码都被编译生成到最终可执行文件中，但我猜您应该不会将Debug版本给最终用户使用对吧？

使用delegate解耦

在MVC架构下，使用Observer（观察者）模式将核心逻辑代码与UI界面代码分离似乎天经地义的事，这样做的好处是核心逻辑代码可以独立于UI代码而存在，从而达到重用的目的。但不幸的是，从笔者经手的代码看，很多程序员并没有注意到这一点。主要问题可能包括以下两个方面：

第一是核心逻辑代码与UI界面代码相互调用关系错综复杂。由于核心逻辑代码不独立，因而很难进行提取复用。这种情况相对比较常见。

第二个问题解释起来可能更复杂一些。由于缺乏从核心逻辑代码到UI界面代码的回调机制，程序员可能会被迫使用一些极端的手法来达到侦测指定事件是否发生的目的。比如，我们知道游戏客户端都有一个主循环main_loop，方法名称通常叫Update()或Tick()，用于更新每一帧的游戏动画。这时，程序员可能会在该循环中埋伏一些代码以侦测核心逻辑状态的变化情况，从而达到触发事件的目的。这种手法实现了功能，保持了低耦合，却降低了代码执行效率。

这两个问题的解决之道在于观察者模式。这个模式在实现上还是比较复杂的，对每一个要处理事件都需要定义对应的观察者与被观察者接口。这种代码复杂性曾使很多人望而却步（包括本人-___-），为此java中内置了java.util.Observer与java.util.Observable接口，以降低使用该模式的代价。

笔者建议的方案是使用delegate（委托）。没错，就是那个C#中的delegate，它能够极低的设计复杂度实现与观察者模式相同的解耦效果。具体实例这里不再列举，因为网上可以找到很多。如果你使用的是C#，那么你是幸运的；如果你使用的是C++，那么网上同样可以找到设计好的仿真类库；如果你不幸使用了VC6，并且实在找到出路了，那么同学你也许可以去参考一下我的另一篇文章《VC6中简易delegate实现》，或许会有点帮助。

结语

本来还想加点静态变量与通用工厂的话题的，但我发现meyers singleton在VC6中的某种应用模式下会问题（singleton对象的构造函数会被调用两次，T__T），因此先欠着账，等待下次有成熟方案的时候再说吧。不过对此问题诸位看官如果有相关宝贵经验的话不妨提携一二，感激不尽中。

首先来看一个例子：

int main(int argc, char* argv[])
{
const int i=0;
int *j = (int *) &i;
*j=1;
cout<<&i<<endlcout<<j<<endl;
cout<<i<<endl;
cout<<*j<<endl;
return 0;
}

结果是

0012ff7c
0012ff7c

0

1

因为i和j都指向相同的内存地址，所以输出的前两个结果是相同的，但为啥相同的内存里的结果不相同么？－－这就是常量折叠.

这个"常量折叠"是 就是在编译器进行语法分析的时候，将常量表达式计算求值，并用求得的值来替换表达式，放入常量表。可以算作一种编译优化。
我只是改了这个地址内容,但是i还是0,

因为编译器在优化的过程中，会把碰见的const全部以内容替换掉（跟宏似的: #define pi 3.1415,用到pi时就用3.1415代替），这个出现在预编译阶段；但是在运行阶段，它的内存里存的东西确实改变了!!!

6.网上的一些问题（4）

关于常量

这些天被常量的一些概念折磨着,现在终于有些明白了，

问题始于const int i = 10;//i存在哪，10存在哪

说明一：符号表

这个语句是对i的声明，因为编译器一开始就知道i的值，所以以后出现i时就会用10代替，这好像叫做符号表的概念，i就对应10了。

网上一篇帖子上有这样的代码：

const int a = 3;

int *p = const_cast<int *>(&a);

*p = 4;

cout << a;//仍然输出3

这个结果可以用上面的说明来解释

说明二：常量折叠（const folding）与复写传播 (copy propagation)

网上人们普遍反映thinking in c++将const folding译为常量折叠是种误导，我觉得译的还行，本来folding就有折叠的意思，就是把原来的东西变小，而象const int i = 2*2;编译器确实将2*2算成4了，以后碰到i就用4替换，这个计算2*2的过程据说叫常量折叠--const folding，而用4替换i的过程叫做复写传播--copy propagation.他们都是编译器的优化技术

说明三：为常量分配空间

补充一下，这里说的都是const 定义的常量，而非文字常量，

（c++ primer翻译成文字常量--literal constant

the c++ programming language（tcpl）翻译成文字量，还分了不同类型）

至于文字常量存在哪，c++ primer 3ed上说它们是不可寻址的--nonaddressable，尽管它们也存在机器内存某个地方，但无法访问它们的地址

对于int double等类型还好理解，但是对于字符串常量（tcpl里说将字符串文字量作为常量，利于存储与访问时的优化）下面的代码似乎表示字符串常量存储在静态存储区里（字符串文字量是静态分配的--tcpl），那么字符串常量的地址不是可以访问了吗，在静态存储区里

http://bbs.bc-cn.net/dispbbs.asp?boardid=56&replyi...

字符串文字量的类型是常量字符数组--适当个数的const字符的数组

//有关字符常量的存储区的问题

//另外，char a[]和char *a的区别

//"hello world 1"存在哪
#include <iostream>
using namespace std;
int main()
{

char* p = "hello world1"；
char a[] = "hello world2"；
//会为a在栈上分配13个字节的空间
// p[2] = a;
a[2] = a;
char* p1 = "hello world1"
printf("%xn",&p[2]);//p应该指向常量区
printf("%x",&a[2]);//栈上数组第三个元素的地址
return 0;
//结果42f036 //这是常量区
//12ff6e果然不一样，这是栈区
}

6.总结

那么"常量折叠"到底是啥意思呢？

我理解，简单的说就是，当编译器处理const的时候，编译器会将其变成一个立即数。

《thinking in c++》里面说这一点在数组定义里尤其重要(为啥呢？没有查到相关的资料)。

Technorati : Zoundary, test, 常量折叠

版本：0.1

最后修改：2010-11-22

撰写：李现民

概述

const在c++中意味着“不可改变”，但在有些情况下我们可以“合法”地绕过编译器去修改一些const数据，比如const_cast就可以剥离一个对象的const属性。然而，我们这样做在多大程度上是“合理”的，却因不同的问题而论，也许一不小心，你就可能掉入陷阱之中。

以下问题，我只分析，不说话，请各位看官自己判断。

当目标是一个常数

这件事源于在网上看到的一篇文章，其来源已经不可考，但大意是：就如下C++程序，其输出是什么：

void foo()
{
const int a = 1;
int* p = const_cast<int*>(&a);
*p = 2;
printf(" a= %d\n *p= %d\n &a= %x\n p= %x \n\n", a, *p, &a, p);
}

我在VC2008下的实测结果为：

a = 1
*p = 2
&a = 12ff6c
p = 12ff6c

好了，问题出现：明明p所指向的就是变量a，但为何打印其值时a!=*p？

这并非是我用错了const_cast，也不是编译器进行了优化的问题。事实上，在各版本的VC与g++下的运行结果均是如此。

以下是VC2008下debug版本的汇编代码：

const int a = 1;
0041146E mov dword ptr [a],1
int* p = const_cast<int*>(&a);
00411475 lea eax,[a]
00411478 mov dword ptr [p],eax
*p = 2;
0041147B mov eax,dword ptr [p]
0041147E mov dword ptr [eax],2
printf(" a= %d\n *p= %d\n &a= %x\n p= %x \n\n", a, *p, &a, p);
00411484 mov esi,esp
00411486 mov eax,dword ptr [p]
00411489 push eax
0041148A lea ecx,[a]
0041148D push ecx
0041148E mov edx,dword ptr [p]
00411491 mov eax,dword ptr [edx]
00411493 push eax
00411494 push 1
00411496 push offset string " a=\t%d\n *p=\t%d\n &a=\t%x\n p=\t%x \n\n"... (415808h)
0041149B call dword ptr [__imp__printf (419318h)]

从printf()的四个参数入栈过程中我们可以看出：指针p的确指向变量a了，而变量a处的数值也的确被改写成2了，问题是：当压入a的值的时候，编译器直接压入了其原始数值1。

关键其实在于：const_cast所操作的目标是否为基础数据类型（char, int, float, double等），如果是类（或结构体）对象则又将是另一番情形。

当修改字符串常量

这个问题最早见于一篇文章《Solmyr的小品文系列之一：字符串放在哪里？》，在这里我只不过转述一二。

代码如下：

void foo()
{
char* str1 = "watch";
const char* str2 = "watch";
char str3[] = "watch";

str1[0] = 'm';

std::cout<< str1 << std::endl << str2 << std::endl << str3 << std::endl;
}

VC6中Release版本运行结果如下：

match
match
watch

VC2008中Release版本运行结果如下：

watch
watch
watch

容易看出：这段代码的运行结果决定于编译器，因为我们改写了不应该被改写的常量数据。更根本的原因是：由于编译器优化，str1与str2实际上指向的是同一份”watch”字符串。

这还带出了另一件事：尽管str1的声明中不带const，但它所指向的字符串数据隐含是const类型的。

注意：这段代码只有Release版本才能顺利执行，Debug版版本运行时会得到一个Access violation 。

版本：0.1

最后修改：2010-11-15

撰写：李现民

概述

很久以前，我写过一篇短文讨论如何在C++项目中避免使用delete的设想，基本方法是使用域（scope）对象或std::auto_ptr代替。尽管当时已经讨论在所有可能的情况，但后面在实际项目实施中发现效果并不好。原因是方面的，比如在使用std::auto_ptr时会存在以下不得因素：

1. 可能的额外开销外（其实很小）；

2. 你需要时刻小心对象所有权的问题。尽管可能只需要稍微注意一下就可以了，但似乎没有任何程序员喜欢过提心吊胆的日子；

3. 你不能在容器（比如std::vector）中存储std::auto_ptr对象；

基于以上原因，类似于Text* pText = new Text;这种直接在堆上申请内存的方式还是在代码得到了大量应用。而接下来就是如何安全、有效的回收这些内存的问题，这也正是本文所讨论的话题。

回收单个堆对象

// delete a object pointer and reset it
template<class T> void delete_null(T*& p)
{
// check if T is incomplete type, if it is, the compiler will report an error
typedef char type_must_be_complete[ sizeof(T)? 1: -1 ];
(void) sizeof(type_must_be_complete);
// delete the pointer and reset it
delete p;
p =NULL;
}

这是一个模板函数，它主要有三个作用：

第一个作用是检查被删除对象的类型完整性。这通常无法引起人们的重视，但在某些情况下可能会导致未定义行为，比如以下代码：

Text* pText = new Text;
void* pData = pText;
delete pData;

Text*类对象pText 被转换成了拥有void*对象pData，并对pData 调用了delete 删除操作。在这种情况下编译器的行为是未知的，但至少有一点：由于编译器无法推导pData 的原始类型，因此无法调用对象的析构函数。

// check if T is incomplete type, if it is, the compiler will report an error
typedef char type_must_be_complete[ sizeof(T)? 1: -1 ];
(void) sizeof(type_must_be_complete);

这两句代码可以检查被删除对象的类型完整性。其效果发生在编译期，如果对类型不完整的对象调用delete_null 删除操作，将引起编译错误。它没有运行期开销，因此使用delete_null 带来的安全性实际上免费的。

更加详细的解释可以参考boost库中的checked_delete.hpp。

delete_null 的第二个作用是回收堆对象，这没有什么可说的。

delete_null 的第三个作用是将对象指针设置为NULL，这主要是为了应对指针有效性检查，属于常规手段。

另外，注意到delete_null 被设计为一个模板函数，在发布版本（Release）中，它将以内联代码（inline）的形式存在，因此不会有运用期函数调用开销。

回收容器中的堆对象

// delete container (std::vector, std::list) items and reset them to NULL
template< typename InputIterator > void delete_null(InputIterator first, InputIterator last)
{
while(last != first)
{
delete_null(*first);
++first;
}
}

// delete functor, used for iterative delete
struct deleter
{
template< typename T > void operator()(T*& p)
{
delete_null(p);
}
};

这段代码分为两部分：一个同样叫delete_null 的模板函数与一个名为deleter的仿函数。

先来看第一部分，它同样叫delete_null，与前面介绍的那个版本所不同的是它接受一对迭代器作用输入条件，其作用是回收[first, last) 范围内所有堆对象。与std::for_each等很多STL标准算法类似，该函数可以同时应用于普通数组或存储单值的标准容器（包括std::vector, std::list, std::set等，不包含std::map）。

第二部分比较有意思：它是一个仿函数。它可以在一定程度上代替delete_null(first, last)，以下代码展示了分别使用这两种方式回收容器中的堆对象的方法：

typedef std::vector<Text*> TextPack;
TextPack uTexts1, uTexts2;
const int datasize = 100;
for (int i= 0; i< datasize; ++i)
{
uTexts1.push_back(new Text);
uTexts2.push_back(new Text);
}

// 使用delete_null
delete_null(uTexts1.begin(), uTexts1.end());
// 使用deleter
std::for_each(uTexts2.begin(), uTexts2.end(), deleter());

可以看到前者稍微简洁一些（包括最终的汇编代码），那么问题来了：为什么还需要代码量更大一些的deleter 仿函数？

理由是：并不是所有存储堆对象的集合都是直接存储对象指针的。比如可以将指针存储在std::map中“值”部分，甚至有些自定义集合只提供了遍历函数（类似于std::for_each），但并不公开迭代器接口。在这些情况下，我们就可以使用deleter 仿函数进行堆对象回收。

注：我（转载本文的人）实测结果是sqrt（）函数要比卡马克的方法更快一些，测试环境xp sp2+ vc6 + stlport

-------------------------------------------------以下是转载原文

好吧，我承认我标题党了，不过既然你来了，就认真看下去吧，保证你有收获。

我们平时经常会有一些数据运算的操作，需要调用sqrt，exp，abs等函数，那么时候你有没有想过：这个些函数系统是如何实现的？就拿最常用的sqrt函数来说吧，系统怎么来实现这个经常调用的函数呢？

虽然有可能你平时没有想过这个问题，不过正所谓是“临阵磨枪，不快也光”，你“眉头一皱，计上心来”，这个不是太简单了嘛，用二分的方法，在一个区间中，每次拿中间数的平方来试验，如果大了，就再试左区间的中间数；如果小了，就再拿右区间的中间数来试。比如求sqrt(16)的结果，你先试（0+16）/2=8，8*8=64，64比16大，然后就向左移，试（0+8）/2=4，4*4=16刚好，你得到了正确的结果sqrt(16)=4。然后你三下五除二就把程序写出来了：

float SqrtByBisection(float n) //用二分法 
{ 
	if(n<0) //小于0的按照你需要的处理 
		return n; 
	float mid,last; 
	float low,up; 
	low=0,up=n; 
	mid=(low+up)/2; 
	do
	{
		if(mid*mid>n)
			up=mid; 
		else 
			low=mid;
		last=mid;
		mid=(up+low)/2; 
	}while(abs(mid-last) > eps);//精度控制
	return mid; 
} 

然后看看和系统函数性能和精度的差别（其中时间单位不是秒也不是毫秒，而是CPU Tick，不管单位是什么，统一了就有可比性） 

从图中可以看出，二分法和系统的方法结果上完全相同，但是性能上整整差了几百倍。为什么会有这么大的区别呢？难道系统有什么更好的办法？难道。。。。哦，对了，回忆下我们曾经的高数课，曾经老师教过我们“牛顿迭代法快速寻找平方根”，或者这种方法可以帮助我们，具体步骤如下：

求出根号a的近似值：首先随便猜一个近似值x，然后不断令x等于x和a/x的平均数，迭代个六七次后x的值就已经相当精确了。 
例如，我想求根号2等于多少。假如我猜测的结果为4，虽然错的离谱，但你可以看到使用牛顿迭代法后这个值很快就趋近于根号2了： 
(       4  + 2/4        ) / 2 = 2.25 
(     2.25 + 2/2.25     ) / 2 = 1.56944.. 
( 1.56944..+ 2/1.56944..) / 2 = 1.42189.. 
( 1.42189..+ 2/1.42189..) / 2 = 1.41423.. 
....
这种算法的原理很简单，我们仅仅是不断用(x,f(x))的切线来逼近方程x^2-a=0的根。根号a实际上就是x^2-a=0的一个正实根，这个函数的导数是2x。也就是说，函数上任一点(x,f(x))处的切线斜率是2x。那么，x-f(x)/(2x)就是一个比x更接近的近似值。代入 f(x)=x^2-a得到x-(x^2-a)/(2x)，也就是(x+a/x)/2。

相关的代码如下：

float SqrtByNewton(float x)
{
	float val = x;//最终
	float last;//保存上一个计算的值
	do
	{
		last = val;
		val =(val + x/val) / 2;
	}while(abs(val-last) > eps);
	return val;
}

然后我们再来看下性能测试：

哇塞，性能提高了很多，可是和系统函数相比，还是有这么大差距，这是为什么呀？想啊想啊，想了很久仍然百思不得其解。突然有一天，我在网上看到一个神奇的方法，于是就有了今天的这篇文章，废话不多说，看代码先：

float InvSqrt(float x)
{
	float xhalf = 0.5f*x;
	int i = *(int*)&x; // get bits for floating VALUE 
	i = 0x5f375a86- (i>>1); // gives initial guess y0
	x = *(float*)&i; // convert bits BACK to float
	x = x*(1.5f-xhalf*x*x); // Newton step, repeating increases accuracy
	x = x*(1.5f-xhalf*x*x); // Newton step, repeating increases accuracy
	x = x*(1.5f-xhalf*x*x); // Newton step, repeating increases accuracy

	return 1/x;
}

然后我们最后一次来看下性能测试：

这次真的是质变了，结果竟然比系统的还要好。。。哥真的是震惊了！！！哥吐血了！！！一个函数引发了血案！！！血案，血案。。。

到现在你是不是还不明白那个“鬼函数”，到底为什么速度那么快吗？不急，先看看下面的故事吧：

float Q_rsqrt( float number )
{
	long i;
	float x2, y;
	const float threehalfs = 1.5F;

	x2 = number * 0.5F;
	y   = number;
	i   = * ( long * ) &y;   // evil floating point bit level hacking
	i   = 0x5f3759df - ( i >> 1 ); // what the fuck?
	y   = * ( float * ) &i;
	y   = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
	// y   = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed

	#ifndef Q3_VM
	#ifdef __linux__
		 assert( !isnan(y) ); // bk010122 - FPE?
	#endif
	#endif
	return y;
}  

float InvSqrt(float x)
{
	float xhalf = 0.5f*x;
	int i = *(int*)&x; // get bits for floating VALUE 
	i = 0x5f375a86- (i>>1); // gives initial guess y0
	x = *(float*)&i; // convert bits BACK to float
	x = x*(1.5f-xhalf*x*x); // Newton step, repeating increases accuracy
	return x;
}  

float InvSqrt (float x) 
{
	float xhalf = 0.5f*x;
	int i = *(int*)&x;
	i = 0x5f3759df - (i>>1);
	x = *(float*)&i;
	x = x*(1.5f - xhalf*x*x);
	return x;
}

好了，故事就到这里结束了，希望大家能有有收获:)

下载代码

TestSqrt.cpp (2.58 kb)

初始时间 = GetTickCount();
while( 消息队列中还有消息 )
{
   从队列中取出第一条消息；
   处理这条消息；
   当前时间 = GetTickCount();
   经过时间 = 当前时间 - 初始时间;
   if( 经过时间 > 20 )
   {
      break;
   }
}
    如果这一帧的处理时间超过了20ms，则把剩下的消息放到下一帧处理。通过这种计时的方式，你会发现游戏的流畅度简直有了天翻地覆的变化！在优化之前，有个几个人在用群攻魔法攻击大量的怪物，这些家伙忽然涌入到视野中，帧率便一下掉到了零点几，游戏出现了非常严重的卡顿，这种状态持续了很短一段时间，帧率又迅速回升上去。而现在，经过修改以后，你会发现那些家伙很平滑地出现在视野中，没有一丝的卡顿。如此效果简直是奇迹一般，而这一切仅仅是修改了几行代码而已。
    现在考虑这么做所带来的问题。如果消息量非常大，而机器又慢，平均帧率又很低的话，那麻烦可就大了：每帧处理的消息量还没有收到的消息量大。这可是个很严重的问题，这会让客户端的表现与实际情况严重脱节。在这里，就需要有一个机制，保证消息在积攒超过一定数量时，能得到及时的处理：

初始时间 = GetTickCount();
while( 消息队列中还有消息 )
{
   if( 消息队列中的消息数量 > 300 )
   {
      一次性处理所有的消息;
   }
   else
   {
      从队列中取出第一条消息；
      处理这条消息；
      当前时间 = GetTickCount();
      经过时间 = 当前时间 - 初始时间;
      if( 经过时间 > 20 )
      {
         break;
      }
   }   
}
    这样就解决了消息越积攒越多的问题，当消息越攒越多时，会一次性处理所有的消息。但这样也会带来一个问题，那就是在帧率比较低的机器上，当需要处理的消息特别多时会出现周期性的卡顿。卡顿的原因就是那步一次性处理所有消息的操作。优化的目的就是要避免这样的卡顿，而对于低端机器来说，这样的优化不但没有起到效果，反而加重了卡顿现象。为了弥补这个方法带来的弊端，就要对那个经过时间20ms做点手脚：

static 时间阈值 = 20;     //注意时间阈值是static的
if( 消息队列中的消息数量 > 100 )
{
   ++时间阈值;
}
else
{
   --时间阈值;
}
if( 时间阈值 < 20 )
   时间阈值 = 20;
if( 时间阈值 > 40 )
   时间阈值 = 40;

初始时间 = GetTickCount();
while( 消息队列中还有消息 )
{
   if( 消息队列中的消息数量 > 300 )
   {
      一次性处理所有的消息;
   }
   else
   {
      从队列中取出第一条消息；
      处理这条消息；
      当前时间 = GetTickCount();
      经过时间 = 当前时间 - 初始时间;
      if( 经过时间 > 时间阈值 )
      {
         break;
      }
   }   
}
    这里增加了时间阈值这个静态变量，替代了之前代码中的20，使之成为一个由当前帧消息包数量决定的一个可变的值。当前帧消息包的数量超过一个值时，就将这个时间阈值加一，否则减一。这么做的效果就是，消息包来得越多，每帧用于处理消息的时间就越长，也就是说消息处理耗时的比重在逐渐上升。这样就能很大程度上降低消息数量超过上限的可能性。
最差的情况，如果这样做依然有周期性卡顿的话，这台机器真的就不适合运行这个游戏了，退一步讲，不作这个优化的话，这台机器玩这个游戏也依然会卡得要命。：）
   当然，时间阈值的范围，和消息包的数量上限可以调整，以适合于不同的游戏。

符号文件——Windows 应用程序调试必备

作者：Generad USam

一、何谓符号文件？

符号文件（Symbol Files）是一个数据信息文件，它包含了应用程序二进制文件（比如：EXE、DLL等）调试信息，专门用来作调试之用，最终生成的可执行文件在运行时并 不需要这个符号文件，但你的程序中所有的变量信息都记录在这个文件中。所以调试应用程序时，这个文件是非常重要的。用 Visual C++ 和 WinDbg 调试程序时都要用到这个文件。
在 Windows 系统中，符号文件以 .pdb 为扩展名，比如：每个 Windows 操作系统下有一个 GDI32.dll 文件，编译器在编译该 DLL 的时候会产生一个 GDI32.pdb 文件，一旦你拥有了这个 PDB 文件，那么便可以用它来调试并跟踪到 GDI32.dll 内部。该文件和二进制文件的编译版本密切相关，比如修改了 DLL 的输出函数，再编译该 DLL，那么原先的 PDB 文件就过时了，不能再用老的 PDB 文件来做调试工作,而必须使用最新的 PDB 文件版本。
Visual C++ 编译代码后会在 Debug 或者 Release 目录下生成一个 PDB 文件。一般情况下，符号文件包括以下的数据信息：

1. 全局变量（Global variables）；
2. 局部变量（Local variables）；
3. 函数名和它们的入口地址（Function names and the addresses of their entry points）；
4. FPO 数据（Frame Pointer Omission)：Frame Pointer 是一种用来在调用堆栈（Call stack）中找到下一个将要被调用的函数的数据结构源代码的行序号（Source-line numbers）；

二、如何得到和安装符号文件?

1. 先确定你的操作系统（OS）版本；
2. 到微软网站下载相应的符号文件；
3. 安装符号文件，对于符号文件的安装位置没有特贝要求，可以安装在任何目录中；
4. 设置环境变量，使得调试工具（比如：Visual C++、WinDbg、Ntsd、DrWatson 等）能找到符号文件；

安装符号文件的注意事项：

如果是手动安装符号文件，有一点很重要，那就是宿主机（Hostt Computer）上的符号文件必须与目标机器（Target Computer）上的 Windows 版本相匹配。
这里所谓的宿主机指的是运行调试会话的机器，在典型的双系统调试会话环境中，宿主机可以是连接到目标机器的任何机器。目标机器指的是发生软件组件、系 统服务、应用程序或操作系统运行失败的机器。也即是需要被调试的机器，它是调试会话关注的焦点。目标机器可以近在咫尺，也可以位于完全不同的地方。有时我 们也将目标机器称之为——被调试者（debuggee），那么与之对应，宿主机则可以称为调试者（debugger）。

三、在 Visual C++ 使用符号文件的方法

在 Visual C++ 6.0 中的使用方法：

1. 打开 Visual C++ 6.0 的 Workspace 文件（*.dsw）；
2. 进入 Tools 菜单，选择 Options 菜单项 (Tools->Options)；
3. 单击 Directoties 标签；
4. 在 “Show directories for”下拉列表中选择 “Executable files”；
5. 将符号文件的路径添加到 “Directories” 路径列表中；
6. 单击  OK 完成；

在 Visual C++ .NET 2003 中的使用方法：

1. 打开 Visual C++ .NET 的项目文件（*.vcproj）；
2. 在解决方案管理器中选中要使用符号文件的项目；
3. 单击右键进入项目属性对话框；
4. 选择“配置属性”中的“调试”；
5. 在与“调试”对应的“操作”选项中有一个“符号路径”，在此添加符号文件的路径即可；
6. 单击  “确定” 完成；

四、如何产生 Release 版本二进制文件对应的 PDB 文件?

在 Visual C++ 6.0 中的方法：

1. 打开 Visual C++ 6.0 的 Workspace 文件（*.dsw）；
2. 进入 Project 菜单，选择 Settings 菜单项 (Project->Settings)，打开项目设置对话框；
3. 在 “Settings for”列表中选择项目的 Release 配置；
4. 单击“C/C++”标签；
5. 在“Category”下拉列表框中选择“General”选项；
6. 在“Debug info”下拉列表框中选择调试信息格式（具体选项参见图一），在此不必禁用任何优化选项；
7. 单击“Link”标签；
8. 在“Category”下拉列表框中选择“Debug”选项；
9. 选中“Debug info”复选框，然后选择需要的链接调试类型（具体选项参见图一）；
10. 不要选择“Separate types”复选框；
11. 在“Project options”编辑框的最后添加如下指令：/opt:ref,icf；
12. 重新生成（Rebuild）项目；

在 Visual C++ .NET 2003 中的方法：

1. 打开 Visual C++ .NET 的项目文件（*.vcproj）；
2. 进入 Project 菜单，选择 Settings 菜单项 (Project->Settings)，打开项目设置对话框；
3. 在 “配置”下拉列表中选择项目的 “（活动）Release” 配置；
4. 选择“配置属性”树型节点中的“C/C++” ==〉“常规”；
5. 设置右边的“调试信息格式”选项（具体选项参见图一）；
6. 选择“配置属性”树型节点中的“链接器”==〉“调试”；
7. 设置右边的“生成程序数据库文件”（具体选项参见图一）；
8. 选择“配置属性”树型节点中的“链接器”==〉“命令行”；
9. 在“附加选项(D)”编辑框中添加如下指令：/opt:ref,icf；
10. 按“确定”退出；
11. 重新生成（Rebuild）项目；

五、关于 Free Build（也称 Retail Build）和 Checked Build（也称 Debug Build）

每个基于 NT 操作系统有两种不同的程序生成模式，即：

• Free Build (或 Retail Build)
• Checked Build (或 Debug Build)

　　Free Build 生成的是最终用户版本，针对生成的二进制文件进行了彻底的优化，禁用了调试断言，并剥离了调试信息。这样一来使可执行程序文件更小，加载更快，使用的内存也更小。
Checked Build 生成的是测试和调试版本。它包含额外的 Free Build 所没有的错误检查，参数验证和调试信息，Checked Build 有助于隔离和跟踪可能导致不可预见的行为的问题，比如内存溢出，不正确的设备配置。虽然 Checked Build 提供了额外的保护，但与 Free Build 比较，它需要更多的内存开销和磁盘空间。由于可执行程序包含符号调试信息；调试时要执行附加的代码、参数检查和输出调试诊断信息，从而导致性能下降。

六、系统符号文件的更新方法

系统符号文件指 Windows 操作系统依赖的那几个重要的 DLL/SYS 和可执行文件对应的符号文件，常见的比如：gdi32.dll、Kernel32.dll、Kerberos.dll、psapi.dll、user32.dll等，使用 WinDbg 调试时，你就会发现系统符号文件(PDB)有多重要，这些文件都与本地的 OS 密切相关，比如，Windows 2000 打了SP补丁的话，那么必须更新系统符号文件才能进行相关调试，原来的符号文件与打补丁后的系统就会不匹配，怎么办呢? 可以通过网络来更新！象下面这样在 WinDbg 的 Symbols Path 里面输入路径：

SRV*D:\Symbols\websymbols*http://msdl.microsoft.com/download/symbols

1. do...while(0)消除goto语句。
通常，如果在一个函数中开始要分配一些资源，然后在中途执行过程中如果遇到错误则退出函数，当然，退出前先释放资源，我们的代码可能是这样：
version 1

这里一个最大的问题就是代码的冗余，而且我每增加一个操作，就需要做相应的错误处理，非常不灵活。于是我们想到了goto:
version 2

代码冗余是消除了，但是我们引入了C++中身份比较微妙的goto语句，虽然正确的使用goto可以大大提高程序的灵活性与简洁性，但太灵活的东西往往是很危险的，它会让我们的程序捉摸不定，那么怎么才能避免使用goto语句，又能消除代码冗余呢，请看do...while(0)循环：
version3

“漂亮！”， 看代码就行了，啥都不用说了...

2 宏定义中的do...while(0)
  如果你是C++程序员，我有理由相信你用过，或者接触过，至少听说过MFC, 在MFC的afx.h文件里面， 你会发现很多宏定义都是用了do...while(0)或do...while(false)， 比如说：
#define AFXASSUME(cond)       do { bool __afx_condVal=!!(cond); ASSERT(__afx_condVal); __analysis_assume(__afx_condVal); } while(0)
粗看我们就会觉得很奇怪，既然循环里面只执行了一次，我要这个看似多余的do...while(0)有什么意义呢？
当然有！
为了看起来更清晰，这里用一个简单点的宏来演示：
#define SAFE_DELETE(p) do{ delete p; p = NULL} while(0)
假设这里去掉do...while(0),
#define SAFE_DELETE(p) delete p; p = NULL;
那么以下代码：
if(NULL != p) SAFE_DELETE(p)
else   ...do sth...
就有两个问题，
1) 因为if分支后有两个语句，else分支没有对应的if，编译失败
2) 假设没有else, SAFE_DELETE中的第二个语句无论if测试是否通过，会永远执行。
你可能发现，为了避免这两个问题，我不一定要用这个令人费解的do...while,  我直接用{}括起来就可以了
#define SAFE_DELETE(p) { delete p; p = NULL;}
的确，这样的话上面的问题是不存在了，但是我想对于C++程序员来讲，在每个语句后面加分号是一种约定俗成的习惯，这样的话，以下代码:
if(NULL != p) SAFE_DELETE(p);
else   ...do sth...
其else分支就无法通过编译了（原因同上），所以采用do...while(0)是做好的选择了。

也许你会说，我们代码的习惯是在每个判断后面加上{}, 就不会有这种问题了，也就不需要do...while了，如：
if(...)
{
}
else
{
}
诚然，这是一个好的，应该提倡的编程习惯，但一般这样的宏都是作为library的一部分出现的，而对于一个library的作者，他所要做的就是让其库具有通用性，强壮性，因此他不能有任何对库的使用者的假设，如其编码规范，技术水平等。

get与set成员函数是为代码耦合之重要原因

版本：0.1

最后修改：2009-08-21

撰写：李现民

类数据成员的访问级别通常需定义为private，以封装类的实现细节，这样可以在类的生命演化过程中提供更好实现弹性。

get/set成员函数（访问级别通常为public）使得client端用户代码可以访问对象的内部数据结构，这会暴露类内部的实现细节。这种暴露使会得用户代码与类实现之间产生深层次的依赖关系，而这种过剩的知识将在类实现技术改变时迅速破坏相关的用户代码---涟漪效果。

比如Container类输出了关于实现该类之二叉树的信息（比如，当它输出成员函数getLeftChild()与getRightChild()时），用户将被迫按照二叉树而不是容器进行思考，这将使用户代码变得复杂且难以改变。如果Container类改变了实现结构，则用户代码将被迫进行修改（可能是大量的）。

最少知识（least knowledge）原则是用于面向对象编码中降低类间耦合度的指导原则。该原则认为如果要在相互调用的类（对象）之间保持较低的耦合度，则一个对象所调用的方法应该仅仅局限于以下几个来源：

1. 类对象本身；

2. 被当作方法的参数而传递进来的对象；

3. 此方法所创建或实例化的任何对象；

4. 对象的任何组件；

一个对象可以任意调用以上四类对象的方法。唯一一类不可调用的方法来源于：通过某个对象的get成员函数所获取的间接对象的成员函数。很容易想象，当某个类拥有大量get/set成员函数时，该类本身几乎不可能提供完善的逻辑处理方法（否则也就没有必要提供这些get/set成员函数了），因此借助get成员函数获取间接对象并做进一步的处理几乎是不可避免的。

因此，在有可能的情况下，类设计人员应该尽量不提供get与set成员函数。

当然，不要认为get与set成员函数总是坏的，像CORBA这样的框架都会为所有的属性自动提供get/set成员函数。真正的问题是：好的对象总会封装并在接口后面隐藏某些东西，然而get/set成员函数有时会在暗中暴露对象的秘密。只有当在类外（从用户的角度）看待这些私有数据仍“有意义”时，为私有数据设置公有的get()和set()成员函数才是合理的。然而在许多情况下， get()/set()成员函数和公有数据一样差劲：它们仅仅隐藏了私有数据的名称，而没有隐藏私有数据本身。

注1：以上文字部分参考了《C++ FAQs》second edition, P73的内容。

注2：我们经常使用get/set成员函数作为急救带来修补蹩脚的接口。

大雨。

乌云象铅块一样低低的压了下来，豆大的雨滴打的玻璃窗啪啪作响，难得一见的异常天气正在竭力表现它令人讨厌的一面。不过这一切似 乎并没有影响到 Solmyr，他仍然以他习惯的舒适姿势半躺在宽大的椅子里，手里还托着一杯热腾腾的果汁，在他背后，zero 在键盘上敲打着什么。

“唉，Solmyr ，标准库中的 stack 怎么会是这个样子？设计糟透了。”zero 停止了工作，转过身来面对 Solmyr ，看起来有些困惑。

“胡乱批评被纳入神圣标准的成员是会遭天遣的。”Solmyr 低着头，以一种算命先生似的语调答道。

不知道上天是否打算加强 Solmyr 的说服力，恰在此时天空划过一道闪电，蓝白色的电光挣扎着努力向地面扑来，紧接着就是“喀喇”一声巨响 ——— 这个雷很近。

一秒钟前还在想“这未免也太扯了”的 zero 表情一下子变得很古怪，良久才恢复正常。他标出了两行代码接着说到：“好、好吧，Solmyr，那请你解释一下为什么 stack 的界面是这个样子。”

std::stack<int> si;
……
int i = si.top();
si.pop();

“只要让 pop() 返回栈顶元素就可以把上面两行合成一行，而且更加直观，为什么要搞成现在这样？”

目睹了 zero 表情变化的 Solmyr 强忍住放声大笑的冲动 ——— 老天知道他忍的有多辛苦 ——— 缓缓的把杯子放到桌上，转过身来开始讲解这个问题：

“原因在于异常。”

“异常？”

“对， 很多代码在没有异常的时候工作的挺好，但是一旦出现异常就变得不可收拾，就像一间茅草屋，平时看起来没什么问题，一遇到今天这种天气 …… ”，Solmyr 指了指窗外，“ …… 立刻就会垮掉。考虑一下如果 pop() 返回栈顶元素需要怎样实现，假设栈内部用数组实现，且不考虑栈是否为空的问题。”

“很简单啊。”，zero 打开了编辑器，写下：

template <typename T>
T stack<T>::pop()
{
   ... ...
   return data[top--]; // 假设数据存储于数组 data 中，top 代表栈顶位置
}

Solmyr 摇摇头：“这就是茅草屋。要知道 stack 是个模板类，它存放的元素 T 可能是用户定义的类。我来问你，如果类型 T 的拷贝构造函数抛出异常，会出现什么情况？”

“嗯 …… 按值返回，返回值是个临时对象，该临时对象以 data[top] 拷贝构造 …… 嗯，这样一来函数返回时可能抛出异常，客户此时无法取得该元素。”

“还有呢？”

“还有？”

“提示，你的 top 怎么了？”

“ …… 哎呀！糟了！top 此时已经减一，栈顶元素就此丢失了！这样的话 …… 必须实现一个函数允许客户修改 ……”，zero 说不下去了。他想了一会，摇摇头承认失败：“不行，这里拷贝构造发生在函数返回之后，无论如何无法避免这种情况。只能在文档里写明：要求 T 的拷贝构造函数不抛出异常。” zero 停了一停，小心翼翼的问 Solmyr ：“这个不算过分的要求吧？”

Solmyr 的回答异常简短：“new”

“哦对，new 在分配内存失败时会抛出 std::bad_alloc …… 算我没说。Solmyr ，我明白了，为了处理异常的情况，调整栈顶位置必须在所有数据拷贝完成之后，所以按值返回是不可接受的。”

“正确。所以对于一个设计目标是最大限度可复用性的标准库成员而言，这是不可接受的。” Solmyr 顿了顿，继续说到：“而且异常带来的影响远不止此。我刚才说‘假设栈内部用数组实现’，但如果你充分考虑抛出异常的各种可能性，你就会发现用数组实现是糟糕的主意。”

“ …… …… …… …… …… 这是为什么？在没有传值返回的情况下，我们总可以捕捉到发生的异常并加以处理啊？”，zero 谨慎的发问。

Solmyr 赞许的看着 zero 。“发问之前先自行思考，习惯不错。”，Solmyr 心想，但是脸上一点也没表现出来：“没错，但捕捉到异常不代表你总能正确的处理它。考虑一下 stack 的赋值运算符，如果我们用数组来实现，那么在拷贝数据的时候肯定会有类似这样的一个循环：”

// 各变量的意义与上面相同
template <typename T>
stack<T>& stack<T>::perator=(const stack<T>& rhs)
{
   ... ...
   for(int i=0; i<rhs.top; i++)
       data = rhs.data;
   ... ...
}

“现在考虑类型 T 的赋值运算符可能抛出异常，该怎样修改上面的代码。” Solmyr 停了下来，再度捧起了杯子。

“用 try 把 …… 哦 …… …… …… …… …… ……”，zero 似乎发现了问题所在，沉默良久，才接着说到：“这个循环可能在运行到一半的时候抛出异常，这样会导致一部分数据已经成功赋值，另一部分却还是老的。除非我 们用 catch(...) 捕捉所有异常，忽略之并继续赋值。”

“但是这样 ……”，Solmyr 有意识的引导 zero 继续深入思考。

“…… 但是这样，赋值运算符抛出的异常就被我们‘吃掉了’，异常总是代表着某些不该发生的事情发生了，所以应该让客户接收到这个异常才对。” zero 皱着眉头，一字一顿，显得相当辛苦。

“正 确。stack 作为一个通用的标准库成员，在面对异常时必须做到两点。一、异常安全，也就是说异常不会导致它本身处于一种错误的状态或是导致数据丢失或是造成资源泄漏； 二、异常透明，也就是说客户代码 ——— 这里指它存放的类型 T 的实现 ——— 抛出的任何异常，不应该被‘吃掉’或者被改变，应该透明的传递给客户。一望即知，上面的代码无可能同时做到这两点。”

“是这样，我懂了，这大概就是标准库中的 stack 不用数组实现的主要原因了吧”，zero 露出了很有把握的神情。

“当然不是！有点常识好不好，用数组实现的话 stack 的大小固定，这怎么能够接受呢？！”

又一次的，Solmyr 目睹了 zero 表情发生难以言喻的剧烈变化。这次他没能忍住放声大笑的冲动，连杯子里的果汁也洒了出来，一时间，笑声充满了整个办公室 ——— 不仅仅是他的，还包括了（众位看官应该猜的到吧？）围观同事们的笑声。

驱散了围观者之后，zero 面带愠色的坐下：“有那么好笑吗？”

“抱 歉抱歉，我 …… 哈哈哈 …… 我 …… 哈哈 …… 我只是一时忍不住 …… 哈哈哈哈 …… ”，Solmyr 好容易平息了大笑，坐直了身子，放下了果汁，正色道：“关键在于上面引入的应该遵循的两条原则，也就是异常安全，和异常透明。现在你考虑一下如果 stack 内部的数据以指针存放，怎样在赋值运算符中保证上述两点？”

“ …… 嗯 …… 还是会有上面那样一个循环 …… 呃 …… ”，zero 面有难色。

“提示，不一定非得直接拷贝到 stack 保存数据的内存里。”

“ …… 嗯 …… 不直接拷贝，那么就是 …… 就是拷贝到 …… 啊！我明白了！”，zero 抓住了其中的关键，飞快的写下：

// pdata 代表指向存放数据内存的指针，top 代表栈顶元素的偏移量
template <typename T>
stack<T>& stack<T>::perator=(const stack<T>& rhs)
{
   ... ...
   T* ptemp = new T[rhs.top];
   try
   {
       for(int i=0; i<rhs.top; i++)
           *(ptemp+i) = *(rhs.pdata+i);
   }
   catch(...)  // 捕捉可能出现的异常
   {
       delete[] ptemp;
       throw;  // 重新抛出
   }

   delete[] pdata;  // 释放当前的内存
   pdata = ptemp;  // 让 pdata 指向赋值成功的内存块
   ... ...
}

“只 要这样”，zero 边输入边说，“只要先把数据拷贝到一个临时分配的缓冲区，在此过程中处理异常，然后让 pdata 指向成功分配的内存就行了。这里的关键是让拷贝动作成为可以 …… 呃 …… 可以安全的取消的，剩下的赋值动作就是简单的指针赋值，肯定不会抛出异常了。”

“非常好。值得指出的是，这是一种相当常见的手段，有个名字叫做 copy & swap ，它不仅仅可以用来应付异常，也可以有效的实现一些其他特征。OK，这个问题大概就是这样了。”

问题似乎可以告一段落了，Solmyr 开始打算就此结束这个话题。可 zero 疑惑的表情阻止了他。

“还有什么问题吗？zero ？”

“啊 …… 没什么，我只是在想，异常导致了这么多麻烦，这一次，还有上一次的线程死锁问题（参见“小品文系列”的前一篇，“成对出现”）都是因为异常的存在才会变得如此复杂的，那为什么 C++ 还要支持它呢？有错误完全可以在返回值里报告嘛。”

“嗯， 这确实是个常见的疑惑，不过答案也很简单，异常的存在有它自己的价值。一、使用异常报告错误可以避免污染函数界面；二、如果你希望报告比较丰富的错误信 息，使用一个异常对象比简单的返回值要有效的多，而且避免了返回复杂对象造成的开销；三、也是我认为比较重要的，有些错误不合适用返回值来报告。举个例 子，动态内存分配。我问你，C 语言中怎样报告动态内存分配错误？”，Solmyr 转过头来看着 zero 。

“malloc 函数返回一个 NULL 值代表动态内存分配错误。”

“但是你见过多少 C 程序员在每次使用 malloc 之后都检查返回值？”

“ …… ”

“没有是吗？这很正常，每次使用 malloc 之后检查返回值是件令人痛苦的事情，所以即使有 Steve Maguire（注：《Writing Clean Code》一书的作者）这样的老程序员谆谆教导、耳提面命，还是有数以万计的 C 程序中存在这样的代码：”，Solmyr 顺手键入：

/* 传统 C 程序 */
int* p = malloc( sizeof(int) );
*p = 10;

“一旦 malloc 失败返回 NULL，这个程序就会崩溃。然而如果是 C++ 程序，使用 new 的话 …… ”，Solmyr 键入了对应的代码：

// C++ 程序
int* p = new int;
*p = 10;

“就不存在这样的问题。我问你，这是为什么？”

zero 很快找到了答案：“因为如果 new 失败，它会抛出 std::bad_alloc 异常，于是函数在此中断、退出，下面这一行也就不会被调用了。”

“正 确。而且你不必在每一处处理这个异常，你只要保证你的程序对异常透明，就可以在 main 函数中写下 try ... catch 对，捕获所有未捕获的异常。比如你可以在 main 函数中捕捉 std::bad_alloc，在输出‘内存不足’错误信息，然后保存所有未保存的数据，完成所有的清理工作，最后结束程序。一言以蔽之，体面的退出。”

zero 点着头，喃喃的重复着：“对，体面的退出。”

见 zero 领会了他的意思，Solmyr 继续开始下一个议题：“异常的存在还有最后一个重要价值 ——— 也是当初设计它的初衷之一 ——— 提供一个通用的手段让构造函数可以方便的报告错误：因为构造函数没有返回值。”

“还有析构函数也是。”没等 Solmyr 说完，zero 就加上了这一句。

Solmyr 对着自作聪明的 zero 摇了摇头：“不要想当然，关于异常有一个非常重要的原则：永远不要让你的析构函数抛出异常。知道为什么吗？”

“ …… 不知道。” zero 这次决定老实承认。

“因为抛出异常的析构函数会导致最简单的程序无法正确运行，比如下面两句：”这次出现在屏幕上的，是看来似乎毫无瑕疵的两行代码：

evil p = new evil[10];
delete[] p;

“看上去一点问题也没有是么？仔细分析一下 delete[] p 这一句，它会调用 10 次 evil 类的析构函数，假设其中第 5 次 evil 类的析构函数抛出异常，会出现什么情况？”

zero 陷入了沉思，视线盯着屏幕一动不动，神情看起来就象是一段执行复杂运算的程序，而且是没有输出的那种。不过没多久，zero 就换了一种表情，这种表情通常被形容为胸有成竹：“我知道了 Solmyr ，在这种情况下，delete[] 面临两难选择。选择一是不捕捉这个异常，让它传播到调用者那里，但这样一来 delete[] 就被中断了，后面的 5 个 evil 对象占用的内存就会无法释放，导致资源泄漏；选择二是捕捉这个异常以防止资源泄漏，但这样一来这个异常就被 delete[] 吃掉了，违反了‘对异常透明’的原则。所以无论怎么做，都没法妥善的处理析构函数抛出异常的情况。”

Solmyr 赞许的点头：“非常好。接下来，你的任务是 ……”

“我知道我知道，把这些讨论整理成文档是吧？我这就动手。”

zero 转过身去，开始埋头于他的文档。而 Solmyr 则再度恢复了半躺半坐的舒适姿势，捧起了他的果汁，并且略略有些意外的发现 ———

天气放晴了。

“为什么会这样？！”，zero 一边喝水一边嘟囔着，恨恨的看着面前显示器上的代码，“为什么这么简单的一个调用也会出现编译错误 …… ”

“这是因为你的设计太差！”

噗！zero 被幽灵一样出现在背后的 Solmyr 吓了一大跳，一口水差点全喷出来。

“咳！咳咳！S …… Solmyr ，你什么时候站在我背后的？”，zero 很费力的平息了咳嗽，同时努力回想刚才自己有没有把柄会被 Solmyr 抓到。

Solmyr 抓过一张椅子坐了下来：“在你一开始干傻事的时候我就在了，正是这个糟糕的设计导致了现在困扰你的编译错误。”

“哪 …… 哪里？”

“这儿。” Solmyr 抓过键盘，标出了下面这段代码：

void SomeFunc(int i)
…………

void SomeFunc(float f)
…………

int main(void)
{
    …………
    SomeFunc(1.2);         // Error! ambiguous call
   …………
}

“我 也正觉得奇怪”，zero 一如既往的挠着头，试图压榨不存在的智慧，“这么简单的一个函数重载，应该很清楚才对。我这里调用时明明给出的是浮点数，显然应该调用 float 版本的 SomeFunc 。最奇怪的是如果没有这个调用，整个程序编译连接完全没有问题，可见这样重载函数是合法的。”

“嗯，没错，确实是合法的，但是合法不代表正确。zero ，你念一下这一段，看看先知 Meyers 在他的《50 诫》（注：指《Effective C++ 2/e》一书）中的条款 26 中是怎样描述 C++ 对待‘模棱两可’的哲学的。”，Solmyr 翻开了一本书，指着其中的几行。

“C++ ……”

“站起来，大声念！”

zero 依言站起，中气十足的念道：“C++ 也有一个哲学信仰：它相信潜在的模棱两可的状态不是一种错误。”

旁边的座位上传来低低的窃笑声，更远处的人探头张望，投来好奇的目光，zero 顿时感到自己像个傻瓜。当 zero 看到 Solmyr 嘴边招牌式的坏笑时明白了过来：自己又一次被 Solmyr 设计了。

“嗯，明白了这一点，我们就可以展开进一步的讨论了”，Solmyr 开始转入正题，“还记得上次我说过上面的 1.2 是什么吗？”

zero 露出了回忆的表情：“嗯 …… 1.2 是‘写在代码里的常量’…… 应该是一个 double 类型常量。”

“这就是问题所在：编译器看到这个调用函数的请求，会去寻找你的重载函数中哪个函数能够匹配这个调用请求给出的参数，结果它发现没有一个函数的参数是 double 类型的，所以必须要做类型转换，但是 double 类型既可以转成 int ，也可以转成 float ，究竟转哪个好呢？编译器不知道，所以只好报错了。明白了吗？”

zero 似懂非懂的点了点头。

“那我问你，这样重载编译时会不会报错？”，Solmyr 稍稍改动了一下 zero 的代码：

void SomeFunc(int i)
…………

void SomeFunc(double db)
…………

int main()
{
   …………
    float f = 1.2;
    SomeFunc(f);
    …………
}

zero 看了看，学着 Solmyr 的语气说到：“编译器发现没有一个函数的参数是 float 类型的，所以必须要做类型转换，但是 float 类型既可以转成 int ，也可以转成 double ，究竟转哪个好呢？编译器不知道，所以只好报错了。”

“错！”，Solmyr 顺手按下了运行按钮，程序运行一切正常，输出显示调用的是 double 版本的 SomeFunc 函数。

zero 再度感到了困惑：“为什么同样是要选择类型转换，这个就没错，前一个就有错呢？这中间的逻辑何在？”

“重要的是这一句：‘究竟转哪个好呢？编译器不知道’。你没有注意到我说这句话的时候‘好’字上用了一个重音吗？”

“你用过重音吗？”

“ …… 这个不是重点。重点在于，float 到 int 和 float 到 double 这两个转换，编译器是能够选择的，因为 float 到 int 会损失数据 —— 象样的编译器会在做这种类型转换的时候给出一个 warning —— 而 float 到 double 则不损失数据，所以编译器知道‘转哪个好’。而之前的情况，double 到 int 到 float 的转换都要损失数据，所以编译器不知道‘转哪个好’，它没办法做一个决定 —— ”，Solmyr 看了看 zero ，再度问道，“明白了吗？”

zero 皱着眉头，挠头挠的更起劲了，显然对于消化一下子出现的这么多信息感到少许困难：“我想我明白了，关键是编译器能否区分两个类型转换。在这里区分的关键是 类型转换是否损失数据，嗯 …… 所以我只要在所有用到浮点数的场合都使用 double 类型，就不会有问题，即使别人用 float 来调用也一样。”

“正确。不过‘模棱两可’的问题可不仅仅出现浮点数身上，例如，这样两个重载函数 …… ”，Solmyr 接着键入：

void SomeFunc(double db)
void SomeFunc(char ch)

“如果我用一个整形变量来调用，会出现什么事情？”，Solmyr 扭头盯着 zero。

“呃 …… 编译器同样无法区分 int 到 double 和 int 到 char 这两个类型转换，所以同样会报错。”

“正确。你能够自己举出几个例子吗？”，Solmyr 把键盘递了回去。

很明显的，zero 陷入了沉思，过了一会儿，屏幕上出现了这样几行代码：

// 用 int 调用的话会出错
void fun(char ch)
void fun(int* pi)            // 或者其他指针

// 用 int 调用同样会出错
void fun(double db)
void fun(int* pi)             // 或者其他指针

“嗯，很好。不过你还是漏了一种重要情况，”，Solmyr 补充道，“就是参数有缺省值的时候：”

// 调用时如果不给参数会出错
void fun(int i=10)
void fun()

“天哪！”，zero 看起来快要崩溃了，“居然有这么多模棱两可的陷阱，这叫我怎样发布我的函数？在文档里写：以下 153 种调用方式将导致编译错误吗？”

“不要这么紧张，”，Solmyr 好整以暇的说到，“重载函数的模棱两可现象不是不能避免的，办法有两个：一是用模板来代替重载，尤其是象你的 SomeFunc 这样 int 型和 double 型处理算法相同的情况；二是如果要用重载的话，尽可能保证函数的参数个数不同。”

“可是如果处理算法不一样，函数需要的参数个数又相同，那该怎么办？”

“很简单，加入‘无用的参数’，象这样：”

void SomeFunc(float db, int)
void SomeFunc(int i)

“第一个函数的第二个参数没有任何作用，所以你可以干脆不给它命名，只要声明一下有这个 int 型参数就可以了。文档里可以这样写：该参数是为今后升级预留的余地，调用时请传入 0 值。”

“ …… 你的文档里大概都是这一类的话吧 …… 啊！好痛！这回又是一本书！”，zero 被 Solmyr 突如其来的袭击击中，发出了悲惨的哀鸣。

“你得感谢先知 Scott Meyers，他的《 50 诫》轻而薄，我手上拿的若是一本教主 Bjarne Stroustrup 的《圣经》（注：指《The C++ Programing Language 3/e》一书，Bjarne Stroustrup 是 C++ 语言的设计者），你现在已经爬不起来了。”，Solmyr 再度披上了修养的伪装，不过言辞中仍然留着一点点杀气的痕迹 ……

“真是残暴的家伙 ……”，zero 小声嘟囔着。

“你说什么？”，杀气再度升高。

“不， 不！我什么也没说！”，zero 连忙否认，试着转移话题，“啊！我懂了，要避免模棱两可的陷阱，一是用模板来替代重载，二是利用加入‘无用的参数’这一手段保证重载函数参数个数不同。这 样就可以避开模棱两可的问题，是不是，Solmyr 老师？”。zero 很努力的装出天真无邪的样子。

“ …… 真是拙劣的演技 …… ”，Solmyr 心中暗想。“不完全，上述手段只能解决函数重载这一块而已，模棱两可问题涉及的情况要广泛的多，比如《 50 诫》中的例子：”

class B;              // 前置声明

class A
{
public:
    A(const B&);   // A 可以根据 B 构造出来
};

class B
{
public:
     operator A() const;    // B 可以被转换为 A
};

“这两个类本身没有什么问题，但若是有个函数需要 A 的对象作为参数，传过去的却是个 B 的对象时：”

void f(const A&)
B b;
f(b);      // Error! ambiguous call

“注 意到这里面的问题了吗？有两种一样好方法可以完成转换，一是用 A 的构造函数以 b 为参数构造一个新的 A 类对象，而是调用 B 的转换函数将 b 转换为一个 A 类对象。编译器再度无法区分哪个转换更好，只能报错了。后面还有一个多重继承的例子，你自己看吧”

“这 …… 这 ……”，zero 刚刚建立起来的对回避陷阱的自信再度崩塌。

“要回避一切模棱两可的问题是不可能的，”，Solmyr 站起身来，“关键是了解它为什么会发生，怎样的情况容易诱发它，然后小心的加以处理，C++ 中很多问题都是如此。这块《 50 诫》的石板就留给你了，好好研读吧。哈哈哈哈！”，Solmyr 一边笑着一边离开了 zero ，背影看起来像是一位飘然远去的高人 ……

“什么呀！根本就只是一个性格残暴的家伙而已，装模做样 …… 啪！”，zero 话音未落，一个文件夹划破空气飞来，正中 zero 的面门。

“呜 ～ 我什么也没说 ～”，zero 无力的辨白，然而换来的只是旁边的座位上再度传来低低的窃笑声而已。zero 明白，今天他的形象算是彻底的毁了 ……