C++博客-ACG狂人-随笔分类-C++

boost::asio网络传输错误码的一些实验结果（recv error_code）

酿妹汁 — Fri, 06 May 2011 10:06:00 GMT

错误码很重要，可以由此判断网络连接到底发生了神马事情，从而驱动高层逻辑的行为。只有笼统的错误码判断的网络层是不够规范的，鄙人觉得有些错误码还是需要在网络层就区分开的，特此记录一些当前实验的错误码以及发生原因。

以下是一部分在async_receive()的handler处捕获到的比较有用的错误码

错误码（十进制）	枚举	发现原因
10009	boost::asio::error::bad_descriptor	在一个已经关闭了的套接字上执行async_receive()
995	boost::asio::error::operation_aborted	正在async_receive()异步任务等待时，本端关闭套接字
10054	boost::asio::error::connection_reset	正在async_receive()异步任务等待时，远端的TCP协议层发送RESET终止链接，暴力关闭套接字。常常发生于远端进程强制关闭时，操作系统释放套接字资源。
2	boost::asio::error::eof	正在async_receive()异步任务等待时，远端关闭套接字，这里跟10054发生的情况似乎一样，但是实际上应该是有区别的，具体神马区别，由回复中jack的说法，这个是远端正常关闭套接字。

只是一些浅陋的测试，目前觉得有用的也就是这几个，不正确的地方请送我鸡蛋。

酿妹汁 2011-05-06 18:06 发表评论

OGRE与MFC的文件系统冲突问题

酿妹汁 — Wed, 29 Dec 2010 12:49:00 GMT

这两个东西在一起问题真呀么多......前些日子才写的一个注意事项的随笔，这回又有问题需要记录，好吧，开新文写。
问题：由于项目的复杂度，问题的表现与原因其实相差十万八千里。
原因：MFC在打开和保持文件后（即打开CFileDialog对话框后），就会修改进程的当前目录，就是SetCurrentDirectoy()，导致OGRE里那些用相对路径做Location的资源目录下的文件全部无法读取（其实我觉得OGRE应该把这些相对目录在读取文件的时候换成绝对目录）。具体就是openResource()中调用stat()出错，文件系统中找不到指定文件。
解决方法：在合适的地方调用SetCurrentDirectoy()把进程当前目录设置回进程工作目录吧......

于是又是一下午+半个晚上的调试时间......

酿妹汁 2010-12-29 20:49 发表评论

备忘随笔系列2：内存错误

酿妹汁 — Thu, 23 Dec 2010 15:41:00 GMT

接上文《备忘随笔系列1：MFC与OGRE联姻注意事项》之后，再记录一下内存错误，经过无数次莫名其妙的内存问题之后，发现一些找不着北的内存Crash问题出现的原因都很荒谬，所以本篇主要例举一下近期出现的一些怪异内存问题和让人啼笑皆非的原因所在。

问题1：编译器在编译那些访问成员变量的代码时算错了相对于this指针的偏移字节数；赋值给下面一个变量时，却修改了上面一个变量的值。
原因：与我共事的某位大仙由于酷爱使用结构体传递网络包，所以在某头文件里用#pragma pack(1)包括住了整个头文件，一不小心把#include "其他头文件"那些行也给包括了进去，其中不乏Windows.h stl云云......
解决办法：当然那个啥......把#pragma pack(1)的位置往下去几行，还是细心点吧...浪费了整整一天调试。

问题2：从网络另一端机器发过来一个结构体，分别接收一个结构体中的多个数据成员和一次性接收整个结构体取出的数据不同。
原因：这是个很2的情形，两个相同的结构体分别在不同的头文件中，且一个有#pragma pack(1)，一个没有。
解决办法：如果要用结构体传递网络包，还是共用头文件吧......

其实......很多内存问题很不好描述，我也不经常出现如上那样纠结的问题，所以下面我还是说一个最常见的内存问题（0x.....地址访问冲突）和原因吧：
“0x.....地址访问冲突”这个Crash基本上每个人都遇到，而且经常遇到，但是大部分都很容易解决。判断问题的原因可以看这几点：
原因1：如果0x....这个值很小，一般就比0大一些，而且是在访问某对象中的数据成员时出错的，那么这基本都是因为该对象指针为空，你用了空对象指针调用了代码。
原因2：如果0x...值同样很小，但是并非在访问某对象中的数据成员时出错，而是调用某函数那一行时出错的，那么这个函数十有八九是个虚函数，如果我说中的话，那原因应该如前面的原因1相同，只是这回是读取虚函数表时就崩了。
原因3：如果0x...值类似是0xcdcdcdcd和0xeeeccc或者与这相近的数，且同样是在访问数据成员或调用虚函数的时候出的问题，那么这就算是个野指针问题了，释放了就别再用啊。
原因4：内存越界，这个对程序造成的麻烦比任何麻烦都要大，但是问题并不隐蔽，记得为每个类的数据成员进行必要的初始化。
原因5：使用了memset或ZeroMemory清空一些对象或对象数组。特别是对象数组，很容易让人忽略这个问题。有些程序员会觉得某对象里都是可以这样清空的数据成员，所以便这样做了，但是往往虚函数表指针会被忽略，这个指针绝对不能一起被清空的。
总结：不要让表达索引的整形在初始化后是个未知值；不要让指针没有在初始化时被赋0值；不要不检查指针的值就拿它访问成员函数和成员数据；不要重复释放指针所指对象；不要使用释放后和未初始化的内存数据；可以的话使用智能指针；释放指针所指地址后，为指针赋0值；只有在完全是内部类型构成且没有多态的类型对象上使用memset为对象赋值。

酿妹汁 2010-12-23 23:41 发表评论

备忘随笔系列1：MFC与OGRE联姻注意事项

酿妹汁 — Wed, 22 Dec 2010 17:39:00 GMT

细节决定那啥来着，一些细节虽然不是什么难事，但是一旦卡住总是会很烦心，需要太多时间去调试，耽误的是宝贵的项目进度，所以我将在这里把一些总结贴出来，愿能给国内的游戏技术圈同僚们一点小帮助，节约宝贵的时间，毕竟总是在网络上摄取营养，算是回报社会吧。

本文记录最近发现的一些 MFC 和 OGRE1.7.2版本联姻的注意事项：

问题1：创建Ogre的CView窗口后，无法截获鼠标点击和移动信息，只能获取鼠标滚轮信息。
原因及解决方案：传递CView窗口句柄时，请一定使用externedWindowHandle的属性key，切记不要使用parentWindowHandle，因为parentWindowHandle是让CView成为渲染窗口的父窗口，鼠标键盘消息都不会路由到CView上，而是在渲染窗口里被截获；而externedWindowHandle是让CView窗口本身成为渲染窗口，所以CView才能正常截获到输入消息。

问题2：当解决问题1之后，发现使用externedWindowHandle绘制出的窗口很小，而使用parentWindowHandle时则正常
原因及解决方案：注意继承CView::OnSize()函数响应WM_SIZE消息，但请切记：千万别在OnSize中调用Ogre::RenderWindow::resize()函数，这会导致OnSize()函数的递归回调，因为Ogre::RenderWindow::resize()函数中会调用AdjustWindow()和SetWindowPos()函数，这会导致发送WM_SIZE消息并缩小窗口，从而导致问题的发生。

问题3：如何解决窗口重置大小的问题
解决方案：在OnSize()中不能调用Ogre::RenderWindow::resize()函数，而应该调用Ogre::RenderWindow::windowMovedOrResized()函数，通知RenderWindow在渲染前重新设置Viewport的宽高比例。

问题4：怎样确保主渲染循环
分析：上网看了一些相关的解决方案，发现大多使用WM_TIMER消息来维持OGRE的主渲染循环，这应该是下下策的方案了吧......当然还有其他的实现方案，譬如开另一个线程，这个方法还是可行的，但是总有些不对味，因为渲染明明应该在主线程中才是最佳方案。于是我就看了一下MFC闲下来的时候都干了些什么，最后发现了以下解决方案，应该算是很不错但并不难的解决办法了，为什么没见网上有人提供这样的方案让我很不理解，窝着藏着也得不到半点好处：
解决方案：使用空闲回调。该回调是需要继承CWinApp::OnIdle()函数（好像是叫这个，反正肯定带Idle这个单词），当主线程中的消息循环没有取到消息时（调用PeekMessage()没有获取到消息），就会去调用这个函数，于是......就在这个函数里调用绘制一帧吧：Ogre::RenderWindow::update()，另外有动画的话还需要调用Ogre::Root::_fireFrameRenderingQueued()，因为动画更新在这里。如果是想让所有渲染对象都更新一帧的话，直接调用Ogre::Root::renderOneFrame()吧。

解决方案不一定最好，也不一定适合你的情况，但愿能尽微薄之力，也是作为我个人的备忘吧。

酿妹汁 2010-12-23 01:39 发表评论

关于MVC PropertySet OperatorStack的一些设计思考

酿妹汁 — Sat, 20 Nov 2010 11:30:00 GMT

最近在给公司里码一个场景编辑器，大致得实现的功能有：
地形高度刷
地形纹理刷
放置小物件和房屋
放置粒子系统
设置路径点和只能摄像机点

算是个简单的不能再简单的场景编辑器了吧...但是这样的一个工具还是很头痛的，特别是用C++来写...
头痛的原因不是别的，正是这个表现层和后台数据同步问题。这个在C++的UI库中目前还真没有什么现成的好办法，于是开始造轮子，为MFC写了PropertySet和OperatorStack。
首先这个UI数据和内存数据双向同步的问题直接让我崩溃了...由于以前写过一些工具，知道这东西如果不做个设计就开始冲着功能写的话会有什么后果。嗯，于是继承封装了CMFCPropertyGridCtrl控件，为每个叶子属性项封装了一个LeafItem，根据属性名来更新PropertySet里对应的数据......具体实现几千字略- - 最终成型时代码这样：
DynamicObject obj;
propertyGrid.attachObject(obj);
这里的DynamicObject继承PropertySet，于是propertyGrid控件就会显示obj里所有的属性数据了...然后是双向更新问题，目前是给Property里加了一个eventValueChanged事件响应，让PropertyGridCtrl监听这些数据的变化，而propertyGridCtrl这个UI上的数据变化同样是派生实现CMFCPropertyGridCtrl的值变化响应函数来给绑定的LeafItem更新数据，也是直接就刷新到Property里了。
还有OperatorStack.....这个是操作栈，记录用户操作的，用于撤销和重做的操作，也用到了PropertySet来记录变化对象的属性快照，嗯，叫SnapShootRecord的类里面记录的都是一个对象的变化属性。
先就记录这么多，很乱很不容易懂，主要给我自己做个记录的，没啥贡献，实际上还有很多不好用的地方，所以最近在想一些改进设计，等我想好了放上来详细设计和源码吧.......

酿妹汁 2010-11-20 19:30 发表评论

终于完成了自己的模板设计，初步实现了filter_streambuf，cge项目启动......

酿妹汁 — Tue, 12 Oct 2010 11:37:00 GMT

实现的目的是为了在一些特定情况下不去使用boost的filter_streambuf，不使用boost::iostreams的理由如下：
1、基于运行时配置的过滤器，效率稍低
2、对于网络通讯而言，boost的filter_streambuf乃至整个iostreams库都显得较为臃肿。
所以，我自己编写了一套filter_streambuf，继承了std::streambuf，并配合自己重新设计的archive和batch_data进行网络通讯，无论是效率还是易用性上都超出使用boost的iostreams。而boost的那套东西经过我的反复使用后，觉得更适合用在文件读写和数据持久化上。
如果要说哪里不如boost的filter_stream，也就是boost的filter_streambuf可以动态配置filter，而我使用的是模板技术将filter的关系在编译期就关联了起来，所以只能是静态配置filter。下面是具体使用时的完整例子代码：

1 #include <ccs/util/ios/ifilter_streambuf.hpp>
2 #include <ccs/util/ios/ofilter_streambuf.hpp>
3 #include <ccs/util/ios/memory_terminal.hpp>
4
5 using namespace ccs;
6 using namespace util;
7
8 // 输出过滤
9 struct my_ofilter
10 {
11     typedef ios::ofilter_tag tag_type;
12
13     template<typename OutT>
14     std::streamsize write(const char* p, std::streamsize n, OutT& _out)
15     {
16         std::streamsize i = 0;
17         for (; i < n; ++i)
18         {
19             char c = p[i];
20             if (_out.write(&++c, 1) != 1)
21                 break;
22         }
23         return i;
24     }
25 };
26
27 // 输入过滤
28 struct my_ifilter
29 {
30     typedef ios::ifilter_tag tag_type;
31
32     template<typename InT>
33     std::streamsize read(char* p, std::streamsize n, InT& _in)
34     {
35         std::streamsize i = 0;
36         for (; i < n; ++i)
37         {
38             char c;
39             if (_in.read(&c, 1) != 1)
40                 break;
41             p[i] = --c;
42         }
43         return i;
44     }
45 };
46
47 // 输出内存设备
48 struct memory_odevice
49 {
50     typedef ios::dest_tag tag_type;
51
52     std::streamsize write(const char* p, std::streamsize n, ios::memory_oterminal& _out)
53     {
54         return _out.write(p, n);
55     }
56 };
57
58 // 输入内存设备
59 struct memory_idevice
60 {
61     typedef ios::source_tag tag_type;
62
63     std::streamsize read(char* p, std::streamsize n, ios::memory_iterminal& _in)
64     {
65         return _in.read(p, n);
66     }
67 };
68
69
70 int main(int _Argc, char** _Args)
71 {
72     char buf[256];
73     ios::memory_oterminal memout(buf, 256);
74     ios::memory_iterminal memin(buf, 256);
75     ios::ifilter_streambuf<ios::memory_iterminal, mpl::list2<my_ifilter, memory_idevice> > insbuf(&memin);
76     ios::ofilter_streambuf<ios::memory_oterminal, mpl::list2<my_ofilter, memory_odevice> > outsbuf(&memout);
77     std::istream is(&insbuf);
78     std::ostream os(&outsbuf);
79
80     int num = 188;
81     os.write((char*)&num, sizeof(int));
82     os.flush();
83     is.read((char*)&num, sizeof(int));
84
85     std::cout << num << std::endl;
86     system("pause");
87 }

代码中的意思就是将写入的数据逐字节的加1，并保存在内存缓冲里，然后又从内存缓冲中读出，逐字节减1，并输出到控制台，一套经过过滤的读写流便完成了。由于使用了模板元的list作为链接，在release模式下所有的过滤器操作都是内联的，这虽然也是我预想的效果，但看完汇编码之后，着实让我高兴了一晚上，这种成就感真的是programer最大的乐趣。

需要说明的是：代码中的mpl::list2是自己实现的模板元链表...过段时间考虑研究一下boost的并替换过来，因为那个list后面的2让我觉得很不够智能...当然，如果boost的list实现过于复杂，或是不能让我的代码完全内联化的话，肯定不会考虑使用。

完成这个之后，我便准备着手构建cge项目，所谓的cge，就是cloud game engine的缩写...顾名思义就是使用了云技术的游戏引擎，我想在业余时间尝试一些颠覆传统cs架构的在线游戏引擎架构设计，具体难点估计会有2个：
1、运用gpgpu group的并行运算技术，考虑使用目前市场占用率最大的nvidia tesla服务器配合cuda，在服务器用physX实现一定的物理模拟。
2、在即时性较强的在线游戏中，ping值一直是最大的挑战，所以有选择性的使用云计算技术，这是架构设计上的挑战。
关于cge的设计思考和规划，会另外开贴具体阐述，并记录开发进度和情况。

酿妹汁 2010-10-12 19:37 发表评论

析构过程中内存相关错误的绝大多数原因

酿妹汁 — Thu, 01 Jul 2010 07:47:00 GMT

今天记录一下长久以来屡次犯的错，每次都是换一种方法编码来绕过这个问题实现功能的，因为这个问题太过隐蔽，导致今天才发现其中真正的原因...下面进行问题描述：

1std::map<std::string, Value> keyValue; // 在函数内部分配的堆栈对象（局部变量）
2ReadData(keyValue);// 从dll中导出的函数
3keyValue.clear(); // delete中出现assert异常

第一行是在应用程序中的堆栈中分配的内存空间。
第二行是我自己写的dll库，用来读取一些数据加入到keyValue中。
第三行是清空keyValue，其实如果不写这一行的话，keyValue也会在函数结尾时清空，到那时同样会出现错误。
这一切乍一看没啥问题，keyValue是局部变量，为什么局部变量的释放会出现异常错误呢？这是因为第二行ReadData的缘故。ReadData的逻辑在另外一个可执行模块中，在其中分配的内存空间不一定与当前模块在同一个堆区。
我们知道，std::map是一个树结构的容器，我在ReadData内部往keyValue中添加了数据，keyValue中会在堆区中分配树节点，而这个节点将会在当前模块在keyValue的析构中被释放。也就是说，我无意中在dll模块中分配了堆空间，又无意中在exe模块中企图释放该空间，这样的行为导致错误是不足为怪的。
时刻牢记，在一个模块中分配和释放同一块内存区域，警惕你所看不见的内存分配和释放。

酿妹汁 2010-07-01 15:47 发表评论

完成的网络数据包文档化

酿妹汁 — Sat, 24 Apr 2010 12:34:00 GMT

好久没写blog了，这次初步完成了一个文档化的网络流框架，这玩意儿是咱自己这样叫，但具体是啥玩意儿呢？其实就是将网络通讯数据结构给串行化到缓冲里，再发送到网络的另一端，由另一端再串行化到相应的类型对象里。恩，这听起来没啥难度呀，但事实并非如此，呵呵，该架构建立在asio基础之上，目前完成了tcp通讯部分，基本可以很方便的使用了。
为啥我要写这么个架子，因为网络通讯需要考虑很多情况，如粘包、未接收完整、缓冲不够大等情况，而且在项目开发过程中，不断的添加和修改一些通信协议相关的数据包结构。为了让程序员不要管那么多麻烦的情况，同时易于修改和添加新的通讯协议，于是就写了这么个架构，不过今天比较忙，还是下次传上用例代码吧，源码可能会在不久以后发布的通用库模板库里找到。
恩，咱要发布自己的一个开源库，建立在stl和boost基础上，可跨平台编译 0 0......
到时候再说了。

酿妹汁 2010-04-24 20:34 发表评论

封装MySQL时解决的两个字符集问题

酿妹汁 — Fri, 09 Oct 2009 14:29:00 GMT

在我开始封装MySQL C API时，真的没有想过居然会在字符集问题上连续卡壳，折腾了一下午+一晚上，终于搞定这些问题。下面记录一下我遇见的问题以及解决办法，以作备忘。
首先遇见的当然是中文乱码问题。这个问题相对来说资料比较多，文档写得应该也是很清楚的，但是我没心思看，靠猜搞定。我首先设置MySQL服务器的默认字符集为UTF8，并保证我操作的表中的列字符集也是UTF8，然后重启MySQL服务，并尝试用mysql_query("INSERT INTO TestTable VALUES('你好')")来写入，结果失败在预料之中。我猜可能可以使用类似"INSERT INTO TestTable VALUES('\0x2734\0x3432')"这样的方式写入中文，但这样太丑了，也没有实用价值，我坚决不会去用。我又尝试使用MultiByteToWideChar去做，甚至使用了Qt的QTextCodec去转换“你好”这两个字，结果依然失败。这就有些蹊跷了，我决定调用mysql_character_set_name()看看到底有没有正确的设置成UTF8格式，让我意料之外的是：结果是latin1，这难道是拉丁字符集？？我查看了一下API函数的相关说明，发现这里获取到的是客户端链接的字符集，我突然觉得，也许MySQL可以自动的在客户端与服务器之间的字符集进行转化！说做就做，我查到了可以用mysql_options()或者mysql_set_character_name()函数来设置客户端链接字符集，但这两个函数用的时机分别在调用mysql_real_connect()之前或之后。我将客户端链接设置成gb2312字符集，这是VC中支持中文的标准字符集之一（另一个标准是UTF16，需要用wchar_t wstring和常量字符串前的L），结果，当然是非常正确的插入中文啦，呵呵！
正当我觉得下面的封装肯定会顺汤顺水之时，在封装基本完成的时候，我发现控制台不能输出我从MySQL取出的中文了！这太奇怪了，输出英文就没有问题，而中文虽然的确被准确无误的读入了std::string中（通过单步调试和ofstream得到确认），然而输出到cout中却会出错。为什么文件流没问题，控制台流会出问题呢？我跟踪了代码，发现在fputc()函数中出现了问题。另一个奇特的地方，就是在mysql_init()函数被调用之前，cout可以正确输出中文，但调用之后就不能输出，iostate被赋予4值，即badbit。我求了一下google，发现sputc()中的一个_nolock_write()函数是msvcrtd.lib中的函数，晕了，我在单步调试中也发现就是这里有问题，确切的说，mysql_init()函数被调用后，_nolock_write()函数就会出错。哈哈，总结出了这些特点之后，我已经隐约猜到了是哪里的问题了，还记得前几日才写的blog里的东西，我由于想要将libmysql.lib换成mysqlclient.lib静态库，所以便禁掉了msvcrtd.lib库，我肯定这里面有关联。
到底是什么原因呢？我觉得，由于这个MySQL的SDK不是我自己编译的，mysqlclient.lib里面调用crt函数时，对字符集的本地化做了设置，由于是欧美的字符集设置，所以一旦我调用了mysqlclient.lib里的函数，就无法再显示中文了。
猜出了问题的根源，那么如何解决这个问题呢？我可以肯定的是，使用std::cout.imbue(std::locale())是行不通的，那么下面就是列出的几个办法：
1、使用人家编译好的动态库，libmysql.lib，并将libmysql.dll拷贝过来，由于动态库和你的程序共享crt dll，因此字符集设置应该会是一致的。
2、如果你还是想用静态库，可以考虑自己下载源码并编译一遍，这是根本的解决办法。
3、如果你可以自己编译，且想用mysqlclient.lib，那么就重新编译mysqlclient吧，动态静态都可以。不过官网上下载的编译好的mysqlclient.lib是静态的，不能使用。

我最终的解决办法是第1种，因为比较懒，不想自己再去编译了，呵呵。

酿妹汁 2009-10-09 22:29 发表评论

原来静态库是这样链接的

酿妹汁 — Tue, 06 Oct 2009 13:30:00 GMT

最近在win32平台下封装MySQL的客户端C API时，出现的问题着实让我头痛了个把小时，不过多亏这一来，我终于明白了静态库是怎样链接的，结合了以前我对动态库与静态库之间进行比较的一些测试结论，也明白了为什么静态库需要这样的设计。不由感叹一下古人的那句话：“挫折果真是成功的母亲。”（好大雾^_^!）
闲话不多说，记录一些关键点，首先是静态链接到底和动态链接有哪些不太容易发现的区别呢？我来假设libA依赖libB，那么我的执行文件在使用libA的时候也需要导入libB才能正确链接，但若dllA依赖libB的话，则只需导入dllA就可以。我在一开始用MySQL时使用的内嵌数据库模式，所以导入的是那个libmysql.dll动态库，因此没出现问题。而换上了mysqlclient.lib后，居然告诉我没有找到socket相关的实现，即“无法解析的外部符号”这类错误，于是乎我只有加上ws2_32.lib库才能通过。
为什么这样设计？原因其实跟静态库的连接方式有关，由于静态库直接将函数实现和全局静态变量导入到包含它的执行体中，所以在多层多重的库包含中就会有大量重定义的问题存在，想想你在一个静态库中用了单件模式，那么其他库又包含你这个库，最后exe又包含所有这些库，最终形成菱形依赖，如果静态库不这样设计的话，问题就会像C++的多重继承问题一样。之所以静态库这样设计，跟C++的虚拟继承思想简直如出一辙。（我知道这段话其实只有已经懂了的人才能看得懂，不过没办法，我表达能力挺笨的...）

还有个极度郁闷的地方是：mysqlclient.lib中的libcmtd.lib和msvcrtd.lib这对活宝居然也被链接进去了，我这边首先需要忽略这两个默认库，然后再包含msvcrtd.lib才可以。我不知道为啥sdk提供的静态库非得在c runtime link的方式上跟一般人过不去，又懒得去自己编译，哎！将就一下就这么用吧......

酿妹汁 2009-10-06 21:30 发表评论

异常处理的可恶陷阱

酿妹汁 — Sun, 02 Aug 2009 09:12:00 GMT

也许这个错误是很幼稚的，但是他着实难住了我好几个小时，一度我还以为永远解不开这个谜题了(*o*)，情况是这样的，异常在抛出之后，到达处理异常的catch域，但这时上下文必须依然有效才行，否则catch将接收不到抛出的异常。具体代码如下：

    try
    {
        moeutil::simple_pool spool(32);
        void* p1 = spool.malloc(15);
        void* p2 = spool.malloc(10, 2);
        void* p3 = spool.malloc(15, 4);
        void* p4 = spool.malloc(7);
        void* p5 = spool.malloc(7);
        void* p6 = spool.malloc(70);
        //std::cout<
        spool.free(p1);
        spool.free(reinterpret_cast<char*>(p2)+2);
        spool.free(p3);
        spool.free(p4);
        spool.free(p5);
        spool.free(p6);

    }catch (moeutil::Exception& e){
        std::cout<<e.what()<<std::endl;
    }

这是一个简易的内存池类，其中simple_pool的析构函数会抛出异常，然后free函数也会抛出异常。析构函数可以检测是否有内存泄漏，而free函数是检测到无效的传入指针时会抛出异常。析构抛出异常是没问题的，但是free抛出异常的时候问题就来了，当free抛出异常时，由于会脱离try块，所以spool也会被析构，这样就会陷入麻烦，由于没有全部free，所以析构本身也会抛出异常，导致了类似于异常迭代的情况。也就是说，在throw一个异常的过程中又一次触发了异常。于是windows系统的debug error对话框出现了，而且是出现在throw那一行。
此随笔用于提醒自己勿犯第二次！

酿妹汁 2009-08-02 17:12 发表评论

使用boost库需要一定的素质

酿妹汁 — Thu, 30 Jul 2009 10:19:00 GMT

        可能由于在几个博客上发布了一些boost库使用心得的关系，最近总是被一些相关的询问邮件骚扰，而提问者问的问题却又让我不知道如何回答才好，或者说根本没有办法回答。一些问题根本就不该问的，所以便发些感慨，还望看了本人一些心得又不禁想问一些偷懒问题的各位手下留情，不要再问我一些奇怪的问题了(*w*)!
        我们学习并使用boost库的目的是简化编程，这并不代表简化到你根本不需要去理解原理的地步。我想，如果您希望很好的驾驭boost库的话，那么请对您自己发发狠努力编写代码积累经验，直到您认为boost库中30%的功能您都能够亲自动手实现的时候，才尝试去使用它。类似“怎么让线程组和asio合作使用”之类的问题，我觉得很囧，而且问的人还非常多，给代码都还迷糊。我觉得您想用asio，请先尝试编写线程类和IOCP框架的应用程序，如果您连线程类都写不好，或者连一个多线程死锁和共享区都不能安全排除的话，请先打打基础吧。
        boost库是一个非常有深度的东西，也是智慧的结晶，有很多东西在一定条件下您可以不用深究，但是起码的30%则必须刨根问底，这30%实际上都是很基础的东西，切不可急于一时而至整个工程最终因为boost的一点小问题卡壳，倘若无法驾驭，则不如不用，再急我也没法帮您了！

酿妹汁 2009-07-30 18:19 发表评论

VC编译器中的一些编译时命令备忘

酿妹汁 — Thu, 30 Jul 2009 10:00:00 GMT

// 加载静态库
#pragma comment(lib, "路径+LIB库名")

// 禁止1221号警告
#pragma warning(disable: 1221)

// 导入并加载DLL exe之类的二进制动态库
#import "路径+二进制库名"

// 将ClassName类中的s_Data静态成员变量定义在头文件中时防止重定义
__declspec(selectany) int ClassName::s_Data = 0;

// 当用户使用void func()函数时，编译器将作出警告，并显示“不推荐使用该函数”字样
__declspec(deprecated("不推荐使用该函数")) void func();

酿妹汁 2009-07-30 18:00 发表评论

记录一下C++标准流感悟

酿妹汁 — Wed, 29 Jul 2009 15:46:00 GMT

        今天终于完成了自己的日志库核心的几个类和算法，折腾了许久，感觉安全性很好，一些多线程的死锁问题已经逐个排除了。由于需要跟C++标准库的输入输出流共事，所以么总算自认为理解了C++标准流的一些特性，记下来以供备忘。
        首先是文件流，关于该流的问题，要扯就扯远了，主要说一说std::wofstream的问题。不要被这个w骗了，其实它输出到文件上的依然还是那么回事，没有丝毫的变化。如果你是想输出Unicode到文本文件中，那么你最好是用ios::binary模式，然后一股脑的倒入文件中，如果要是使用<<重载符号的话，输出到文件中的跟std::ofstream没区别，而且中文还无法输出。如果你遇见中文无法输出的问题，恩，可以调用std::wofstream::imbue()方法，具体也就是一行：ofs.imbue(std::locale("chs"));搞定。
我想，C++标准库并不支持Unicode编码，而是给字符地域化的编码方式，中文的可能也就是GBK吧，听说C++0x标准会纳入Unicode编码支持，如果是这样的话就省心多了。
        然后还有个不省心的地方就是流的streambuf中的缓冲大小了，我发现，fstream中的写缓冲居然一直是0啊，这个就很头疼了，需要给文件流指定缓冲的大小。

酿妹汁 2009-07-29 23:46 发表评论

ASIO攻破！！！

酿妹汁 — Fri, 26 Jun 2009 14:14:00 GMT

花了足足3天时间，外加1天心情休整，终于在第5天编写出了一个能运行的基于asio和thread_group的框架，差点没气晕过去，把源码都看懂了才感觉会用了。
测试了一下，debug下一万次回应耗时800+毫秒，release下是200+毫秒，机器配置双核2.5G英特尔，4个线程并行工作，无错的感觉真好，再也不用担心iocp出一些奇怪的问题啦，因为是巨人们写的实现，呵呵。

进入正题，简要说一下asio的实现原理吧。在win32平台上，asio是基于IOCP技术实现的，我以前也用过IOCP，却没想到居然能扩展成这样，真是神奇！在其他平台下还会有别的方法去实现，具体见io_service类下面这部分的源码：

  // The type of the platform-specific implementation.
#if defined(BOOST_ASIO_HAS_IOCP)
  typedef detail::win_iocp_io_service impl_type;
  friend class detail::win_iocp_overlapped_ptr;
#elif defined(BOOST_ASIO_HAS_EPOLL)
  typedef detail::task_io_service<detail::epoll_reactor<false> > impl_type;
#elif defined(BOOST_ASIO_HAS_KQUEUE)
  typedef detail::task_io_service<detail::kqueue_reactor<false> > impl_type;
#elif defined(BOOST_ASIO_HAS_DEV_POLL)
  typedef detail::task_io_service<detail::dev_poll_reactor<false> > impl_type;
#else
  typedef detail::task_io_service<detail::select_reactor<false> > impl_type;
#endif

这部分代码其实就在boost::asio::io_service类声明中的最前面几行，可以看见在不同平台下，io_service类的实现将会不同。很显然，windows平台下当然是win_iocp_io_service类为实现了（不过我一开始还以为win_iocp_io_service是直接拿出来用的呢，还在疑惑这样怎么有移植性呢？官方文档也对该类只字不提，其实我卡壳就是卡在这里了，差点就直接用这个类了^_^!）。

那么就分析一下win_iocp_io_service的代码吧，这里完全是用IOCP来路由各种任务，大家使用post来委托任务，内部调用的其实是IOCP的PostQueuedCompletionStatus函数，然后线程们用run来接受任务，内部其实是阻塞在IOCP的GetQueuedCompletionStatus函数上，一旦有了任务就立即返回，执行完后再一个循环，继续阻塞在这里等待下一个任务的到来，这种设计思想堪称神奇，对线程、服务以及任务完全解耦，灵活度达到了如此高度，不愧为boost库的东西！我只能有拜的份了...

说一下总体的设计思想，其实io_service就像是劳工中介所，而一个线程就是一个劳工，而调用post的模块相当于富人们，他们去中介所委托任务，而劳工们就听候中介所的调遣去执行这些任务，任务的内容就写在富人们给你的handler上，也就是函数指针，指针指向具体实现就是任务的实质内容。其实在整个过程中，富人们都不知道是哪个劳工帮他们做的工作，只知道是中介所负责完成这些就可以了。这使得逻辑上的耦合降到了最低。不过这样的比喻也有个不恰当的地方，如果硬要这样比喻的话，我只能说：其实劳工里面也有很多富人的^o^! 。很多劳工在完成任务的过程中自己也托给中介所一些任务，然后这些任务很可能还是自己去完成。这也难怪，运行代码的总是这些线程，那么调用post的肯定也会有这些线程了，不过不管怎么说，如此循环往复可以解决问题就行，比喻不见得就得恰当，任何事物之间都不可能完全相同，只要能阐述思想就行。

最后还要说明的一点就是：委托的任务其实可以设定执行的时间的，很不错的设定，内部实现则是通过定时器原理，GetQueuedCompletionStatus有一个等待时间的参数似乎被用在这方面，还有源码中的定时器线程我并没有过多的去理解，总之大体原理已基本掌握，剩下的就是使劲的用它了！！！

另外为了方便人交流，在这里插入一些代码可能更容易让人理解吧，
下面这个是启动服务时的代码：

void ServerFramework::run()
{
    boost::thread_group workers;
    for (uint32 i = 0; i < mWorkerCount; ++i)
        workers.create_thread(
            boost::bind(&boost::asio::io_service::run, &mIoService));
    workers.join_all();
}

在打开前就得分配好任务，否则线程们运行起来就退出了，阻塞不住，任务的分配就交给open函数了，它是分配了监听端口的任务，一旦有了连接就会抛出一个任务，其中一个线程就会开始行动啦。

void ServerFramework::open(const String& address, const String& port, uint32 nWorkers /*= DEFAULT_WORKER_COUNT*/)
{
    // Open the acceptor with the option to reuse the address (i.e. SO_REUSEADDR).
    boost::asio::ip::tcp::resolver resolver(mIoService);
    boost::asio::ip::tcp::resolver::query query(address, port);
    boost::asio::ip::tcp::endpoint endpoint = *resolver.resolve(query);

    mAcceptor.open(endpoint.protocol());
    mAcceptor.set_option(boost::asio::ip::tcp::acceptor::reuse_address(true));
    mAcceptor.bind(endpoint);
    mAcceptor.listen();

    mNextConnection = new Connection(this);
    mAcceptor.async_accept(mNextConnection->getSocket(),
        boost::bind(&ServerFramework::__onConnect, this,
        boost::asio::placeholders::error));

    mWorkerCount = nWorkers;
    if (mWorkerCount == DEFAULT_WORKER_COUNT)
    {
        mWorkerCount = 4;
    }
}

open函数中给io_service的一个任务就是在有链接访问服务器端口的情况下执行ServerFramework::__onConnect函数，有一点需要格外注意的，io_service必须时刻都有任务存在，否则线程io_service::run函数将返回，于是线程都会结束并销毁，程序将退出，所以，你必须保证无论何时都有任务存在，这样线程们即使空闲了也还是会继续等待，不会销毁。所以，我在ServerFramework::__onConnect函数中又一次给了io_service相同的任务，即：继续监听端口，有链接了还是调用ServerFramework::__onConnect函数。如果你在ServerFramework::__onConnect执行完了还没有给io_service任务的话，那么一切都晚了...... 代码如下：

void ServerFramework::__onConnect(const BoostSysErr& e)
{
    if (e)
    {
        MOELOG_DETAIL_WARN(e.message().c_str());
    }

    Connection* p = mNextConnection;
    mNextConnection = new Connection(this);

    // 再次进入监听状态
    mAcceptor.async_accept(mNextConnection->getSocket(),
        boost::bind(&ServerFramework::__onConnect, this,
        boost::asio::placeholders::error));

    // 处理当前链接
    __addConnection(p);
    p->start();
}

最后，展示一下这个类的所有成员变量吧：

    // 用于线程池异步处理的核心对象
    boost::asio::io_service mIoService;

    // 网络链接的接收器，用于接收请求进入的链接
    boost::asio::ip::tcp::acceptor mAcceptor;

    // 指向下一个将要被使用的链接对象
    Connection* mNextConnection;

    // 存储服务器链接对象的容器
    ConnectionSet mConnections;

    //// 为链接对象容器准备的strand，防止并行调用mConnections
    //boost::asio::io_service::strand mStrand_mConnections;

    // 为链接对象容器准备的同步锁，防止并行调用mConnections
    boost::mutex mMutex4ConnSet;

    // 为控制台输出流准备的strand，防止并行调用std::cout
    AsioService::strand mStrand_ConsoleIostream;

    // 工作线程的数量
    uint32 mWorkerCount;

但愿这篇随笔也能对正在研究asio的朋友们有所帮助吧。

酿妹汁 2009-06-26 22:14 发表评论

boost::bind绑定成员函数时，第一个参数传递对象的特殊情况

酿妹汁 — Mon, 15 Jun 2009 14:34:00 GMT

boost::bind(&memberfunction, obj, _1, _2........)类似这样的用法，我们叫做成员函数绑定，boost库的文档中说的很清楚，第一个参数可以是value、pointer和reference，即传值、传地址和传引用都是可以的，所以在一般情况下，下面三种使用bind的形式都是成立的。

class A
{
public:
void func();
};

A a;
A& r = a;

boost::bind(&A::func, a);
boost::bind(&a::func, &a);
boost::bind(&a::func, r);

由上面的代码可以看出，我们可以随便传任意一种类对象的形式，函数模板会自动寻找最为匹配的为我们实现。但是有两种情况是特殊的，即：
1、该对象不可进行拷贝构造函数。
2、该对象不可随意被析构。
发现这个问题是在我编写单件模式时的遇见的，当时发现我的单件对象在bind中被析构了一次，这很不寻常，为什么bind会调用第一个参数的析构呢？跟踪进了boost的源码才发现，原来所有的参数都会被拷贝一遍，然后析构一遍，这样一来，我们传递参数的时候就会有一些小麻烦了，首先必须保证参数能够被拷贝而不影响逻辑和数据一致性，其次，参数能够被析构而不影响逻辑和数据一致性。单件是全局性质的数据，所以绝对不可以析构，那么这种情况的话，我们只好传递单件对象的地址，而不能传递值或引用。

另：附上出错问题的代码如下

class InputDevice
    : public EventSource
    , public Singleton<InputDevice>
{
public:

};

class TestUI
    : public Singleton<TestUI>
{
public:
    ~TestUI(){
        std::cout<<"~TestUI"<<std::endl;
    }
    void processKeyboard(EventArgs& args){
        std::cout<<"键盘响应"<<std::endl;
    }

    void processMouse(EventArgs& args){
        std::cout<<"鼠标响应"<<std::endl;
    }
};

int _tmain(int argc, _TCHAR* argv[])
{
    new FrameUpdaterManager;
    new DelayEventSender;
    new InputDevice;
    new TestUI;

    InputDevice::getSingleton().mEventSet.addEvent("KeyDown", Event());
    InputDevice::getSingleton().mEventSet.addEvent("KeyUp", Event());
    InputDevice::getSingleton().mEventSet.addEvent("MouseLDown", Event());
    InputDevice::getSingleton().mEventSet.addEvent("MouseLUp", Event());
    InputDevice::getSingleton().mEventSet.addEvent("MouseRDown", Event());
    InputDevice::getSingleton().mEventSet.addEvent("MouseRUp", Event());

    //TestUI& ui = TestUI::getSingleton(); // 用此行便会出错
    TestUI* ui = TestUI::getSingletonPtr();

    // 出错开始
    InputDevice::getSingleton().mEventSet["KeyDown"] += boost::bind(&TestUI::processKeyboard, ui, _1);
    InputDevice::getSingleton().mEventSet["KeyUp"] += boost::bind(&TestUI::processKeyboard, ui, _1);

    InputDevice::getSingleton().mEventSet["MouseLDown"] += boost::bind(&TestUI::processMouse, ui, _1);
    InputDevice::getSingleton().mEventSet["MouseLUp"] += boost::bind(&TestUI::processMouse, ui, _1);
    InputDevice::getSingleton().mEventSet["MouseRDown"] += boost::bind(&TestUI::processMouse, ui, _1);
    InputDevice::getSingleton().mEventSet["MouseRUp"] += boost::bind(&TestUI::processMouse, ui, _1);

    delete TestUI::getSingletonPtr();
    delete InputDevice::getSingletonPtr();
    delete DelayEventSender::getSingletonPtr();
    delete FrameUpdaterManager::getSingletonPtr();
    return 0;
}

酿妹汁 2009-06-15 22:34 发表评论

log4cxx C++的日志库使用随记

酿妹汁 — Wed, 10 Jun 2009 09:03:00 GMT

log4cxx是一个不错的库，利用配置文件就可以很灵活的使用它。
说说具体用法，首先当然是在你的C++代码中写上Log的各种东西了

#include <log4cxx/logger.h>
#include <log4cxx/logstring.h>
#include <log4cxx/propertyconfigurator.h>

int _tmain(int argc, _TCHAR* argv[])
{
    using namespace log4cxx;

    // 读取配置文件
    PropertyConfigurator::configure("log4cxx.cfg");

    // 建立两个logger
    LoggerPtr logger1 = Logger::getLogger("TraceYourMama");
    LoggerPtr logger2 = Logger::getLogger("Patch");

    LOG4CXX_TRACE(logger1, "跟踪");
    LOG4CXX_WARN(logger1, "警告");
    LOG4CXX_DEBUG(logger1, "调试");
    LOG4CXX_ASSERT(logger1, false, "断言");
    LOG4CXX_FATAL(logger1, "致命");

    LOG4CXX_TRACE(logger2, "跟踪");
    LOG4CXX_ERROR(logger2, "错误");
    return 0;
}

其实在实际应用中，每个类都可以搞一个logger，然后在配置文件中进行如下的设置：

# 设置root logger为DEBUG级别
#log4j.rootLogger=TRACE,ca
log4j.logger.TraceYourMama=ERROR,fa,ha
log4j.logger.Patch=Trace,ca

#设置spirit为TRACE级别
#log4j.spirit=DEBUG
#log4j.additivity.spirit=false

# %m - message
# %n - 回车
# %d - 时间
# %.16c - Logger名称
# %-5p - log级别
# %t - thread_id

#对Appender ca进行设置：
#这是一个控制台类型的Appender
#输出格式（layout）为PatternLayout
log4j.appender.ca=org.apache.log4j.ConsoleAppender
log4j.appender.ca.layout=org.apache.log4j.PatternLayout
log4j.appender.ca.layout.ConversionPattern=%d %-5p %.16c - %m%n

#对Appender fa进行设置：
# 这是一个文件类型的Appender，
# 其输出文件（File）为./debug.log，
# 输出方式（Append）为覆盖方式，
# 输出格式（layout）为PatternLayout
log4j.appender.fa=org.apache.log4j.FileAppender
log4j.appender.fa.File=./debug.log
log4j.appender.fa.Append=true
log4j.appender.fa.layout=org.apache.log4j.PatternLayout
#log4j.appender.fa.layout.ConversionPattern=%d [%t] %-5p %.16c %x - %m%n
log4j.appender.fa.layout.ConversionPattern=%d %-5p %.16c - %m%n

酿妹汁 2009-06-10 17:03 发表评论

boost statechart

酿妹汁 — Sat, 30 May 2009 00:34:00 GMT

接触了boost的状态机，发现不是想象中的那么好用，在一些地方还得用上mpl库里的东西，由于对模板元编程不是很熟练，搞了好些天才算弄明白这该死的mpl::list的原理和用法。
boost的状态机是属于静态链接的状态机，也就是说，它的图结构是编译期间就确定了的，在运行时不可以动态配置。所以，它的用途是有一定局限性的，但在一般情况下，它不仅很通用，而且在你会用并熟练地情况下，还会很好用，用起来很舒服，逻辑也很合理。下面就是一段代码，当然也是借鉴了别人的东西，自己修改了一下，在MainState中添加了一个Transition做了测试，因为此前我还不知道一个状态如何包含多个Transition，呵呵，原来是用mpl::list来做。至于这个状态机的入门教程，网上随处可见的三部曲：《boost 状态机入门教程》说得很清楚。

  1 #include <iostream>
  2 #include <ctime>
  3
  4 #include <boost/statechart/transition.hpp>
  5 #include <boost/statechart/event.hpp>
  6 #include <boost/statechart/state_machine.hpp>
  7 #include <boost/statechart/simple_state.hpp>
  8
  9 namespace sc = boost::statechart;
10
11
12
13 class EvtStartStop : public sc::event<EvtStartStop>{};
14 class EvtReset : public sc::event<EvtReset>{};
15 class EvtGo : public sc::event<EvtGo>{};
16
17
18 class MainState;
19 class StopState;
20 class RunState;
21 class TwoState;
22
23 class Machine : public sc::state_machine<Machine, MainState>
24 {};
25
26
27
28
29
30
31 class MainState : public sc::simple_state<MainState, Machine, StopState>
32 {
33 public:
34     typedef sc::transition<EvtReset, MainState> reactReset;
35     typedef sc::transition<EvtGo, TwoState> reactGo;
36     typedef boost::mpl::list<reactReset, reactGo> reactions;
37
38     MainState(void){
39         std::cout<<"进入MainState"<<std::endl;
40         mTime = 0;
41     }
42
43     ~MainState(void){
44         std::cout<<"退出MainState"<<std::endl;
45     }
46
47     double mTime;
48 };
49
50
51 // 该状态属于无用状态，用于测试mpl::list的多transition用法
52 class TwoState : public sc::simple_state<TwoState, Machine>
53 {
54 public:
55     typedef sc::transition<EvtGo, MainState> reactions;
56
57     TwoState(void){
58         std::cout<<"进入TwoState"<<std::endl;
59     }
60
61     ~TwoState(void){
62         std::cout<<"退出TwoState"<<std::endl;
63     }
64 };
65
66
67 class StopState : public sc::simple_state<StopState, MainState>
68 {
69 public:
70     typedef sc::transition<EvtStartStop, RunState> reactions;
71     StopState(void){
72         std::cout<<"进入StopState"<<std::endl;
73     }
74
75     ~StopState(void){
76         std::cout<<"退出StopState"<<std::endl;
77     }
78 };
79
80 class RunState : public sc::simple_state<RunState, MainState>
81 {
82 public:
83     typedef sc::transition<EvtStartStop, StopState> reactions;
84     RunState(void){
85         std::cout<<"进入RunState"<<std::endl;
86         mStartTime = 0;
87     }
88
89     ~RunState(void){
90         std::cout<<"退出RunState"<<std::endl;
91         context<MainState>().mTime += std::difftime(std::time(0), mStartTime);
92     }
93
94     std::time_t mStartTime;
95 };
96
97
98 int _tmain(int argc, _TCHAR* argv[])
99 {
100     Machine mc;
101     mc.initiate();
102
103     mc.process_event(EvtStartStop());
104     mc.process_event(EvtStartStop());
105     mc.process_event(EvtReset());
106     mc.process_event(EvtGo());
107     mc.process_event(EvtGo());
108
109     return 0;
110 }

酿妹汁 2009-05-30 08:34 发表评论

模版特例化

酿妹汁 — Mon, 25 May 2009 03:14:00 GMT

写模版多了的人，必然会遇到这样那样的问题，模版特例化就是解决了一个经常碰见的问题：如果我们需要根据某些特殊的模版参数类型来重新实现一下算法的话，该怎么办呢？说的多了那也没什么用，我们就写一个会做除法的类吧。这个类在做整数除法的时候会同时求出余数，而在算其他类型时是不求的。代码如下：

1#include <iostream>
2
3
4template<typename Ty>
5class Division
6{
7public:
8    Division(Ty dividend, Ty divisor)
9        :mDividend(dividend), mDivisor(divisor){}
10public:
11    void show()
12    {
13        std::cout<<"结果 = "<<mDividend/mDivisor<<std::endl;
14    }
15
16    Ty mDividend, mDivisor;
17};
18
19template<>
20inline void Division<int>::show()
21{
22    std::cout<<"结果 = "<<mDividend/mDivisor<<std::endl;
23    std::cout<<"余数 = "<<mDividend%mDivisor<<std::endl;
24}
25
26
27
28
29int _tmain(int argc, _TCHAR* argv[])
30{
31    Division<int> a(20, 11);
32    a.show();
33
34    Division<float> b(20.0f, 11.0f);
35    b.show();
36    return 0;
37}

以上这种方式就叫做局部特化，关于全部特化和局部特化、全特化和偏特化，我认为他们之间的关系很紧密，界限也很模糊，硬要分类的话，以上面的Division类为例，就看下面的代码对全部特化和局部特化的区别吧：

1 /**
2 @remark
3  Division的全部特化
4 */
5 template<>
6 class Division<int>
7 {
8 public:
9     Division(Ty dividend, Ty divisor)
10         :mDividend(dividend), mDivisor(divisor){}
11 public:
12     void show()
13     {
14         std::cout<<"结果 = "<<mDividend/mDivisor<<std::endl;
15         std::cout<<"余数 = "<<mDividend%mDivisor<<std::endl;
16     }
17
18     Ty mDividend, mDivisor;
19 };
20
21 /**
22 @remark
23 Division的局部特化
24 */
25 template<>
26 inline void Division<int>::show()
27 {
28     std::cout<<"结果 = "<<mDividend/mDivisor<<std::endl;
29     std::cout<<"余数 = "<<mDividend%mDivisor<<std::endl;
30 }

上面的代码只是说明了全部特化和局部特化，并没有说明什么事全特化和偏特化。其实，对于只有一个参数的模版类型来说，并没有什么全特化和偏特化的区别，但如果是一个以上的模板参数，那就是由区别的了，如下：

1 /**
2 @remark
3 原始模板类
4 */
5 template<typename Ty, typename TyEx>
6 class ObjectData
7 {
8     //
9 };
10
11 /**
12 @remark
13 Object的全特化
14 */
15 template<>
16 class ObjectData<int, float>
17 {
18     //
19 };
20
21 /**
22 @remark
23 Object的偏特化，只特化第一个参数
24 */
25 template<typename TyEx>
26 class ObjectData<int, TyEx>
27 {
28     //
29 };

以上仅为个人观点，错误之处请指正。

酿妹汁 2009-05-25 11:14 发表评论