版本：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, 常量折叠

符号文件——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

BOOL是微软定义的typedef   int   BOOL。与bool不同，它是一个三值逻辑，TRUE/FALSE/ERROR，返回值为&gt;0的整数为TRUE，0为FALSE，-1为 ERROR。Win32   API中很多返回值为BOOL的函数都是三值逻辑。比如GetMessage().

bool是标准C 数据类型，可取值true和false。

根据布尔类型的语义，零值为“假”（记为FALSE），任何非零值都是“真”（记为TRUE）。TRUE的值究竟是什么并没有统一的标准。例如Visual C 将TRUE定义为1，而Visual Basic则将TRUE定义为-1。
假设布尔变量名字为flag，它与零值比较的标准if语句如下：
if (flag) // 表示flag为真
if (!flag) // 表示flag为假
其它的用法都属于不良风格，例如：
if (flag == TRUE)
if (flag == 1 )
if (flag == FALSE)  
if (flag == 0)