论坛上有人问，所以把以前做的东西拿出来秀一下。

Lua是一门小巧精致的语言，特别适用于嵌入其它的程序为它们提供脚本支持。不过脚本通常是用户编写的，很有可能出现死循环，虽说这是用户的问题，但却会造成我们的宿主程序死掉。所以检测用户脚本中的死循环并中止这段脚本的运行就显得非常重要了。

可是，一个现实的问题是死循环并不好检测，一些隐藏较深的死循环连人都很难找出来，更不用说让机器去找了。所以实际采用的方案多是检测脚本的执行时间，如果超过一定的限度，就认为里面有死循环，我下面的例子也是用的这种方法。

以下是几个相关的全局变量（我是喜欢把C++当C用的程序员，C++的忠实粉丝请忍耐一下:)）的定义。

run_user_script用来执行用户脚本，它首先通过GetTickCount把当前的时间记录到g_begin中去。然后将g_counter加一，在执行完用户脚本后再将其加一，这样就可以保证执行用户脚本时它是个奇数，而不执行时是偶数，检测脚本超时的代码可以籍此来判断当前是否在执行用户脚本。还要注意调用用户脚本要使用lua_pcall而不是lua_call，因为我们中止脚本的执行会产生一个Lua中的“错误”，在C/C++中它是一个异常，只有用lua_pcall才能保证这个错误被Lua脚本引擎正确处理。

下面的check_script_timeout用来检测脚本超时，需要在另外一个线程中周期性的调用，原因我想就不用解释了吧。它首先检查是否在执行用户脚本，或者是否已经让当前执行的用户脚本中止过。然后看这段脚本执行了多长时间，超过限度就把当前脚本计数记录到g_check中去，并通过lua_sethook设置一个钩子函数timeout_break，这个钩子函数会在用户脚本执行时被调用。

最后就是那个钩子函数了，它首先把钩子去掉，因为这个钩子只要执行一次就行了。由于设置钩子和执行钩子是在不同的线程中，并且钩子从设置到执行需要一定的时间，所以它要通过对比g_check和g_counter来判断是否还在运行判断超时所执行的那段脚本，不是就什么也不做，是就通过luaL_error产生一个错误，并中止脚本的执行，而这个错误最终会被run_user_script中的lua_pcall捕获。

上面的检测使用了两个线程，其实在一个线程中也可以做到，并且更简单。但那样会导致钩子函数频繁执行，影响效率，如果对性能没什么要求的话，也可以采用。

单件模式可能是所有设计模式中最简单的一个了，但在C++中，尤其是还要支持多线程的话，要想写一个正确的实现却并不容易，不信请看：

 1 class CSingleton
 2 {
 3 public:
 4  CSingleton()
 5  {
 6   _tprintf( _T("CSingleton::Constructor: Before Sleep\n") );
 7   Sleep( 1000 ); // 不会改变逻辑, 但增大了问题出现的概率
 8   _tprintf( _T("CSingleton::Constructor: After Sleep\n") );
 9  }
10  void DoSomeThing()
11  {
12   _tprintf( _T("CSingleton::DoSomeThing\n") );
13  }
14  static CSingleton* GetInstance()
15  {
16   static CSingleton* p = NULL;
17   if( p == NULL )
18    p = new CSingleton();
19   return p;
20  }
21 };
22 unsigned __stdcall thread( void* )
23 {
24  CSingleton* p = CSingleton::GetInstance();
25  p->DoSomeThing();
26  return 0;
27 }
28 int _tmain( int argc, _TCHAR* argv[] )
29 {
30  for( int i = 0; i < 3; ++i )
31  {
32   uintptr_t t = _beginthreadex( NULL, 0, thread, NULL, 0, NULL );
33   CloseHandle( (HANDLE)t );
34  }
35  _getch();
36  return 0;
37 }

上面的单件实现在单线程中肯定是正确的，不过在多线程中的输出却如下：

很明显，虽然我们想做个单件，但它却出现了多个实例（或一个实例被初始化了多次）。其原因是我们的实现根本没有考虑多线程，那下面的代码把创建实例的部分锁住是不是就行了呢？

 1 class CCriSec : CRITICAL_SECTION
 2 {
 3 public:
 4  CCriSec()
 5  {
 6   Sleep( 1000 ); // 增大出问题的概率, 但不改变逻辑
 7   InitializeCriticalSection( this );
 8  }
 9  ~CCriSec() { DeleteCriticalSection( this ); }
10  void Enter()
11  {
12   EnterCriticalSection( this );
13  }
14  void Leave() { LeaveCriticalSection( this ); }
15 };
16 // 
17 static CSingleton* GetInstance()
18 {
19  static CSingleton* p = NULL;
20  static CCriSec lock;
21  lock.Enter();
22  if( p == NULL )
23   p = new CSingleton();
24  lock.Leave();
25  return p;
26 }
27 // 

运行一下，不管输出是什么，程序崩溃了。分析一下可以发现，这个例子中的我们确实控制好了对CSingleton实例的初始化，但这种控制却依赖于另一个静态变量（CCriSec的实例）的初始化，而这个新的静态变量导致了程序的崩溃，也就是说我们在解决问题的同时引入了新的问题。而且，在这种情况下，就算再引入多少个新的临界区也无济于事，因为对最外层的临界区的初始化总会有问题。

上面的例子的问题在于CCriSec是一种复杂的数据类型，所以对它的初始化总要到运行时才能完成，如果用整数这样简单的、能在编译期完成初始化的数据类型来做是不是可以呢？

看起来好像没有问题，但运行一下却是下面的输出：

也就是说DoSomeThing在构造函数返回之前已经被调用了，这显然也是错误的。其原因是我们忽略了“对象的创建时需要时间的”，把这个问题也修正一下，就是最终的正确实现了：

本文采用的单件实现是函数内的静态变量，如果你采用其它方式，也会有类似问题。其实在我看来，单件模式是一个看起来简单、做对了很难（上面演示的是多线程中的问题，在具体的实践中还会遇到很多其他问题）、同时又没有太多实用价值的东西。

另外，从Windows Vista开始，微软提供了一种多线程下对象初始化的方法，有兴趣的可以中搜一下“INITONCE”，个人认为INITONCE有点完美的过头了，真正好玩又有用的是与它同时出现的“条件变量（condition variable）”。

A是典型的数据驱动 + Builder模式, 它最大的优点是增加或删除一个模块只需要增加或删除一个数据项, 耦合很小, 所以看起来非常优雅.

而A的缺点有两个. 和上一篇一样, 其中之一也出在调试上: 当一个模块初始化失败后, 如果我们只看外面这些代码, 没有办法一眼得出是谁失败了, 必须得多一些操作才行.

第二点是A实现强制了模块的初始化和退出顺序, 先初始化的模块后退出貌似很合理, 但在一个大型系统中却总会出例外, 而且还可能出现Module1先初始化一半, 然后Module2初始化, 之后Module1再继续初始化等情况. 当然, 我们可以使用"把初始化顺序和退出顺序定义在两个数组中"或"把初始化划分为多个阶段"等方法处理这些问题, 但这些方法都会增加复杂性, 而且也都不能从根本上解决问题.

B实现则用简单直接的方法很好的避免了A的问题, 虽然它看起来好像很笨, 增加删除一个模块要改多个地方, 但这些改动总共也不过几行代码, 而且往往只涉及一个文件, 所以总体代价并不高.

最后, 本文的场景乍看起来非常适合使用Builder模式, 可为什么使用它的效果不好呢? 我本人对设计模式不感冒也不擅长, 所以只能试着解释一下这个问题: 其原因就是这个场景只是看起来像, 但其实并不适用Builder模式. Builder模式要求对象支持统一的接口, 也希望对象之间没什么关联, 这是我们作设计时追求的目标, 但在实现一个复杂系统时却很难完全满足这些要求, 所以硬套上去就会出问题. 而且在实现一个系统时, 各个模块还不可能完全定下来, 实现过程中的改动也会给Buidler模式带来麻烦. 按我个人的理解, Buidler模式不应被用来处理系统的主体模块, 它真正的适用场合之一是实现对插件的支持, 把所有插件定义在一个列表中, 然后逐项处理, 因为这时系统的主体功能已经完成, 所以可以为插件定义出清晰的接口, 而且就算定义的接口有一点问题, 它所影响的也只是某些插件而非主体功能了.

1. 像cin/cout一样, A实现能把多个操作写在一起.

2. 如果需要跳过一段数据, 需要怎么做呢? 如果用A实现, 肯定是类似下面的方法:

实现文件：

应用举例：

两个c/s结构的网络通讯程序，服务器端使用完成端口模型，客户端使用阻塞模型，双方以一种客户端发送命令，服务器端处理，然后返回应答的方式通讯。问题出在服务器端。以下是服务器端代码的大致处理逻辑：

long volatile g_busy = 0;
void iocp_thread()
{
while( GetQueuedCompletionStatus() )
{
if( InterlockedCompareExchange( &g_busy, 1, 0 ) != 0 )
WSASend( "服务器忙" );
// 处理命令
ProcessCommand();
WSASend( "应答信息" );
InterlockedExchange( &g_busy, 0 );
}
}

其中ProcessCommand需要互斥运行（这是简化的逻辑，实际上有很多不同的命令，有些需要互斥，有些可以并行，否则就没必要用完成端口了），并且需要一定的时间才能处理完毕。为了避免多个客户端同时执行命令，导致所有的iocp线程都等在那，我把g_busy当成了一个锁，第一个线程可以成功进入，其它的都直接向客户端返回“服务器忙”。

程序一直都运行的很好，直到有一天把服务器程序装到了一台有双核cpu的机器上。我发现，如果让客户端连续发送命令，即收到上一条命令的应答后立即发送下一条命令，就会随机的返回“服务器忙”，而这时只有一个客户端连接上去，按照我设想的逻辑是不可能出这种情况的。检查了半天代码，没觉得有什么问题，调试吧，又遇到了另一个难题，海森堡的测不准原理起作用了，做的工作太多问题就消失了，做的太少又得不到什么有价值的信息。搞得我很是头疼。

今天再次看这个问题，突然想到：它肯定和线程切换相关，所以我应该记录下每次处理命令的线程的ID，这样出错时就可以看看上次成功执行命令的那个线程在干什么了。方法正确了，问题也就迎刃而解了，我发现，出问题时，上一个线程的WSASend居然还没有返回，也就是说，客户端已经收到应答并发送了下一条命令，服务器端也收到了命令并准备处理，但上一条命令的应答却还没有完全发送完成，难怪出错了！

总结经验教训，感觉自己一开始被两点给误导了，一是实际程序中的WSARecv/WSASend藏的比较深，没这么明显，所以没注意到。二是当时粗略检查代码觉得没问题，就把主要精力放在ProcessCommand上了，由于我把它里面一段访问sql server的代码注释掉以后，问题就不出了，所以还看了半天atl oledb的源码，最后精疲力尽，其它事情又比较多就放弃了。

所以我决定自己写一个小工具降低一下制作.dmp文件的难度，也就有了今天发布的这个EasyDump（轻松转储）。代码和可执行文件都放到google code（也是刚注册的，尝试一下:)）上去了，大家可以到http://code.google.com/p/easytools/下载。

程序还没有很好的测试过，如果有bug的话，应该可以直接在项目主页上报告。另外下一步考虑增加三个功能：首先是异常过滤，因为first chance异常太多了！如果选择了生成.dmp的话，一秒钟可能就有十个甚至更多的文件，设置了异常过滤后，可以把一些不关心的异常屏蔽掉，不生成文件。其次是如果没有second chance的话，就把first chance的文件直接删掉，也有助于减少不必要的文件。第三是界面的国际化，也发布个英文版什么的。

2009.01.08: 自动删除first chance文件的功能已经实现.
2009.01.22: 异常过滤功能已经实现.

在visual studio中，每个c++ project的general属性页中，都有一项"Inherited Project Property Sheets"，我们可以在这里指定一个或多个Property Sheet（不要和GUI开发中的Property Sheet搞混了，完全两个概念）供项目继承。在被继承的属性表（父属性表）中，我们设置好默认选项，然后把project中对应的选项设置为"inherit from parent or project defaults”就可以使用父属性表中的设置了。这样，在solution层面上准备一个Property Sheet，再让其下的所有project继承，即可实现编译选项的统一管理。

在visual studio的view菜单中选择property manager，还可以更清楚的看到每个project继承了哪些property sheet，并且有更多的编辑功能（如创建新property sheet、清除project已经设置了的选项等）。另外，property sheet还支持多级继承，而实践上一般也是每个solution一个根Property Sheet，然后为每个Configruation（Debug版、Release版等）分别派生出一个，各个project的不同Configruation继承对应的Property Sheet。

最后要注意的就是：property sheet的保存文件（.vsprops），也是应该加入配置管理系统的。

1. 对于clr中的引用类型，定义变量时要用个^符，如"String^ var1"、"array<int>^ var2"、"array<String^>^ strarr"等，值类型不用。一个类型是值类型还是引用类型，取决于定义时用的是value struct/class还是ref struct/class。

2. 定义枚举要用enum struct/class, 否则是个原生枚举，C#里不能用。可指定数值类型和flags属性，如下：
    [FlagsAttribute]
    public enum class TestEnum : unsigned int
    {
       flag1 = 0x00000001,
       flag2 = 0x00000002,
    };

3. 原生字符串转换为托管字符串时，用：
    char* s1 = "native string1";
    wchar_t* s2 = L"native string2";
    String^ str1 = gcnew String( s1 );
    String^ str2 = gcnew String( s2 );
托管字符串转换为原生字符串时，用：
    pin_ptr<const wchar_t> p = PtrToStringChars( str );
如果需要ansi字符集，可再对p进行一些常规字符集转换。

4. 指针、句柄等与0进行赋值比较等操作时用nullptr，而不是NULL或0，后者会导致装箱等操作，如：
    HANDLE h = nullptr;
    if( h == nullptr ){}

5. C#中定义函数参数时的ref关键字在C++/CLI中用%号对应，如：
    void foo( String^% refstr );
out关键字，需要用[System::Runtime::InteropServices::OutAttribute]声明一下。

6. 数组空间初始化，用()而不是[]，也就是说它是一个函数调用，如
    array<int>^ arr = gcnew array<int>(100);
的作用是定义一个有100个元素的数组。

7. C++/CLI中很多地方不能用const、volatile等关键字，如果编译报错，就把它们去掉吧。

8. 尽量不要定义自己的DllMain，如果必须定义的话，DllMain中不要进行任何托管操作，否则极易导致死锁。可以"#pragma managed"编译指令，临时打开或关闭托管。

9. 暂时没有了，等想起来再补充。

1. makecert生成x.509证书和私钥, 会弹出界面要求输入两次密码, 我输的是123, 其中localvar studio是公司名
makecert /sv sign.pvk /n "CN=localvar studio" sign.cer

2. 把x.509证书转换为Software Publisher Certificate
cert2spc sign.cer sign.spc

3. 把pvk转换为pfx, 例子中的123是私钥密码
pvk2pfx -pvk sign.pvk -pi 123 -spc sign.spc -pfx sign.pfx

4. 签名, 稍微调整一下，就能写在post build event里了，123是密码
signtool sign /f sign.pfx /p 123 test.exe

上面的例子只是演示签名过程，由于证书是本机做出来的，所以签了名也没用，用户那看到的仍然是“未知发行商”。向证书颁发机构申请真正的证书时，能直接得到.spc和.pvk文件，所以就不用执行前两步了。

PS: 证书颁发机构真是坐地收钱呀，几秒钟生成个证书，每年就收好几千。

1. 生成一个名为autover的项目

    注意项目的Properties文件夹下有一个名为AssemblyInfo.cs的文件，autover程序的版本号就写在它里面。

2. 创建模板文件

在windows的资源管理器中进入Properties文件夹，把AssemblyInfo.cs文件复制一份，命名为AssemblyInfo.template.cs，并把它加入到项目中来。

3. 修改AssemblyInfo.template.cs的属性

    AssemblyInfo.template.cs文件是用来自动生成版本号的模板文件，它不应该被编译，所以我们要把它的Build Action改成None，如下图所示：

4. 修改AssemblyInfo.template.cs的内容

    在这个文件中，你能找到如下两行代码：
[assembly: AssemblyVersion( "1.0.0.0" )]
[assembly: AssemblyFileVersion( "1.0.0.0" )]
其中的“1.0.0.0”就是程序的版本号，它使用的是“主版本号.次版本号.内部版本号.修订号”的形式。前三个改成你自己需要的数字，最后一个改成“$WCREV$”，改完之后应该是类似下面的样子：
[assembly: AssemblyVersion( "1.0.0.$WCREV$" )]
[assembly: AssemblyFileVersion( "1.0.0.$WCREV$" )]

    在这个文件的最后，你还应该加上下面两段代码，它们可以检测出有本地修改（修改了但没有提交）的代码和有混合版本的代码。
#if $WCMIXED?true:false$
#if DEBUG
#warning mixed update revisions founded
#else
#error mixed update revisions founded
#endif
#endif

#if $WCMODS?true:false$
#if DEBUG
#warning local modification founded
#else
#error local modification founded
#endif
#endif

5. 修改项目属性

    在项目属性的Build Event页的Pre-build event command line中输入：
"%ProgramFiles%\TortoiseSVN\bin\SubWCRev.exe" $(SolutionDir) $(ProjectDir)Properties\AssemblyInfo.template.cs $(ProjectDir)Properties\AssemblyInfo.cs -f
注意，这里我们必须保证TortoiseSVN安装到了默认路径上。在多人参加的项目中这应该是强制性的要求，否则，大家安装的路径都不一样，甲机器上能用的配置，到了乙机器上可能就不行了。

    然后，你可能还需要将Publish页中的Automatically increment revision with each publish选项关掉（我不确定这步是否必须）。C#可以自己递增版本号，但它生成的版本号和代码库中的代码没有对应关系，我个人觉得意义不大。并且它还可能会把我们的版本自增机制搞乱。所以应该关掉。

6. 把项目加入版本库

    使用VisualSVN的Add solution to Subversion命令把项目加入SVN，但不要提交。

7. 从SVN中排除AssemblyInfo.cs文件

    每次编译时，这个文件都会基于AssemblyInfo.template.cs重新生成，所以没必要加入版本库。这步做完之后就可以提交整个项目了。

8. 编译

    编译完成后，看一下生成的autover.exe文件的版本信息，本例中是1.0.0.1。随便改点什么，提交，重新编译，你会发现它自动变成了1.0.0.2，也就是程序的修订号总是与生成它的代码的修订号一致。这样，当程序出问题后，我们通过这个数字就能轻松得到生成它的那一版代码了。

9. 其它问题

    第8步中大家做完修改后再编译时可能会看到警告或错误信息，说代码有本地修改或混合版本。这就是第4步中，在AssemblyInfo.template.cs文件最后加的两段代码的作用，它们检测代码是否都已经提交了并且版本是否一致，一旦发现问题就会在调试版中生成警告信息，在发布版中生成错误信息。使用这种方法，我们可以基本消除发布的程序的版本和代码的版本出现不一致的可能性。去掉这两个错误或警告的方法也很简单，把代码整体提交或更新一下就行了。

    一直认为是①, 今天正在写的程序出错了才发现是②. 老天保佑以前的程序不出错吧. 这个错误一直没发现的原因有两点，一是我用do while循环比较少, 里面有continue的更少; 二是自己偷懒了, 想当然了, 其实以前怀疑过它的结果的, 但觉得①更符合逻辑就没有深究.

    犯了错误总是比较郁闷的, 不过能在一个上午认识到这样两个错误，也算收获不小了。

1. 与其他工具的对比

2. svn能解决哪些问题

    一直以来，XXXX项目都是使用vss作为配置管理工具的，但应用过程中我也越来越感觉到vss满足不了项目的需要，所以决定在项目组内试用svn，并在合适的时机完全转换到svn。具体说来，svn可以解决以下几个（包括但不限于）问题。

2.1. 获取某个以前的版本

2.2. 自动递增版本号

2.3. 变更集

2.4. 离线操作

3. 相关工具和网站

--------------------------------------------------------------------------------

1. 字节对齐

    每种cpu都有其特定的字长, 如目前最常见的32位cpu, 其字长就是32位(4字节), 即将普及的64位cpu, 字长就是64位(8字节). 而cpu对内存的访问总是从字长的整数倍开始, 以字长为单位的. 例如(假设是32位cpu, 下同)读一个32位整数, 如果其起始地址是0, 则只需一次内存操作; 但如果起始地址是1、2或3, 则需要两次操作来将相关的两个字都读出来, 再在cpu内部进行处理才行. 对x86cpu, 这样做仅会稍微降低一点效率, 但如果是某些其它类型的cpu则可能会有成千上万倍的效率损失, 甚至是程序根本无法运行.

    从以上的分析可以看出, 我们定义结构体时, 为了提高效率和可移植性, 应该尽量让cpu以最少的内存操作访问其任意一个成员. 例如对于第一个成员是char型, 第二个成员是int型的结构, 其体积应该是5字节, 但显然在这种情况下cpu对int型成员的访问要两次内存操作, 而不是最少的一次. 所以我们应该浪费一些空间, 在char型成员后面加上3个填充字节, 使int型成员的起始位置对齐cpu字长的整数倍. 不过, 一个像回事的程序会有大量结构定义, 如果都去人为计算, 手工填充, 工作量就太大了. 因此, 编译器特意设置了一个选项(在vs2005中, 它是项目属性|c/c++|code generation|struct member alignment)来配置默认的字节对齐方式, 你可以选择1、2、4、8或者16字节对齐. 如果你什么也没有选的话, 它的默认值是8. 当然, 编译器也并没有搞一刀切, 对于需要特殊处理的结构, 你还可以使用"#pragma pack"编译指令单独为其指定其合适的对齐方式. 注意, 虽然我们从cpu字长引出了编译器的字节对齐, 但它们是两个不同的概念, 一定不要弄混. 从某种意义上, 你可以把字节对齐理解为: 我的程序将运行在字长是这个数值的cpu上.

2. 简单结构

    这里所说的简单结构, 是指仅由编译器内置类型构成的结构. 我们已经知道, 计算其体积, 需要其字节对齐设置, 这里假设其值是N. 则(有点拗口, 多读几遍):
    简单结构的大小, 是其符合"使cpu在任意情况下, 访问其任意成员的内存操作次数不大于'(sizeof(此成员) + N - 1)/N'(这里的除法使用的是C/C++整数除法的语意)"的所有内存布局中, 体积最小的那个占用的字节数. 
    例如结构：
    struct A         和         struct B
    {                           {
        char c;                     double d;
        double d;                   char c;
    };                          };
其sizeof的结果与N的对应关系应该是:

3. 复合结构

     与简单结构相对, 复合结构就是指那些部分或全部成员也是结构的结构. 其实没有必要把它单独列出来的, 因为其大小的计算方法与简单结构完全一样. 唯一要注意的就是: 对其每个成员的大小的计算要按定义这个成员的类型时的字节对齐来进行, 而不能按定义这个复合结构时的对齐设置. 例如:
    #pragma pack( push, 8 )
    struct A
    {
        char c;
         double d;
    };
    #pragma pack( 1 )
    struct B
    {
        char c;
         A a;
    };
    #pragma pack( pop )
sizeof(A)和sizeof(B), 将分别是16和17, 而不是16和10.

4. 特殊情况

    结构体的大小还有几种特殊情况, 一是空结构, 即没有任何成员的结构, 这种情况, 编译器规定其大小是1; 二是如果结构有虚函数, 则它会包含一个虚函数表指针(vfptr, 但这只是一般情况, 具体取决与编译器实现), 它的大小等于cpu字长, 但由于不能直接从定义中看出来, 你数的时候一定不要把它忘了; 还有就是虚拟继承等情况, 不过它们的结果与编译器实现关联太严重, 并且通常也碰不到, 这里就不做讨论了.

PS: 只是大概想了这么多, 如果哪里说错了, 欢迎大家批评指正.

    程序很简单, 我就不做过多解释了, 但正像我在标题中写的, 它只是"一种引用计数的实现"方法而已, 和其他实现相比, 它既有优点, 也有缺点, 所以使用时一定要根据实际情况, 选择最合适的方法.

PS: InterlockedAnd在VS2005中是编译器的一个intrinsic, 如果你使用的编译器不支持它, 可参考我的《对windows互锁函数的补充》, 自己实现一个.