纸箱猪的专栏

C++ Complains about Converting 'int **' to 'const int **'Recently when I was switching a project from C to C++, I found that C++ compilers do not allow converting int ** to const int **, even with explicit cast.After searching on the web and thinking, I th

最近在项目代码中看到了boost::bimap, multiset_of, with_info >这样的类型。虽然我用过boost::bimap，可那只是很简单的应用。这个mulstiset_of让我感到了一点困惑。　　直接在网上搜multiset_of没找到多少有用的信息，看了两篇提到它的文章，还是有点不清楚这是什么东西。后来感觉可能是因为自己在数学上就没接触过multiset这个概

理解了std::multiset之后，理解boost::bimap和boost::bimap::multiset_of就不在话下了。不过在此之前，最好还是先了解下std::multimap： 　　http://blog.csdn.net/believefym/article/details/1627874　　http://www.cplusplus.com/reference/map/

Multiset的中文名是多重集合，其实就是集合的扩展版。唯一的不同是集合中一个值只能出现一次，而多重集合中一个值可以出现多次。 　　粗略看了看MSDN，在STL中，multiset和set的成员函数声明也是基本一样的，一些需要注意的地方是：set::insert(key)的返回值是一个pair，其中pair中的bool成员表明了key被插入之前，set中是否已存在相同的k

源地址：http://blog.codingnow.com/2007/11/inertia_thinking.html晚上在办公室晃荡，对面的同事在加班写代码。我凑上去看看在写什么。我向他了解了后明白了，大约是服务器上角色 buff 的实现吧。BUFF 这个术语是现在网络游戏中非常常见的。给角色加一个 BUFF 通常意味着对虚拟角色的一些数值上的临时修正：例如，攻击

3月28日，《寻龙》不删档测试正式开启。可是才开服几天，服务器就出现了多次崩溃。造成崩溃的代码有三处，其中有两处造成了全服掉线，而且这两处代码都是由我负责的，实在是一大耻辱。　　第一处崩溃位于物品拾取逻辑中。怪物死亡掉落物品的时候，服务器会为每件物品创建一个对象。玩家对物品进行掷骰分配时会用到指向这些物品对象的指针。怪物尸体消失的时候，如果尸体里的物品还没有被拾取，物品对象就会随着尸体

最近一直想研究一下我们项目的程序是如何生成minidump和full dump的。从代码中查到minidump是用google-breakpad生成的，但full dump却不知道是怎么生成的。后来在网上搜了许久，才知道其实full dump也是minidump，只不过是带了额外信息的minidump。所以full dump也是google-breakpad生成的。　　google-b

这事情还得从上上星期说起。最近在跑一个自己写的数据挖掘程序，这程序要跑上两三天，期间要同时向磁盘输出一个220多GB的二进制文件（以下称文件1）和一个450多GB的二进制文件（以下称文件2）。我上上周三就把程序写好了，用的是std::ofstream。 程序跑了两天，到了上上周五早上，我欢欢喜喜地去上班，准备收结果。谁知到了办公楼下，在配电箱上卖力捣腾的电工扭头看见我，对我说：“停电了。”——这段...

10月24日，周四　　我负责的游戏启动程序（Launcher）更新上线后，临下班前接到运营消息，反映部分网吧启动Launcher后无反应。跑到客服现场，通过QQ远程桌面观察到如下现象：双击程序图标后，程序出现在任务管理器进程列表里，但无任何其它反应，没有任何界面弹出；然后程序就一直这样无任何响应，只能在任务管理器中把进程杀掉。　　于是在现场通过Process Explore

放假在家，继续调试《家园》。目前的进度是MinGW上的编译链接都已通过，游戏程序也已经可以跑起来并进入主菜单界面，但加载关卡之后就会闪退。这让我想起了以前上中学时玩盗版游戏的日子。那个年代的单机游戏估计大多是用C/C++写的，一个不小心的内存操作就会让进程崩掉；而且那个年代的操作系统没现在稳定，可能破解技术也不够先进，从电脑城里买来的五六块钱的盗版游戏质量参差不齐。很多游戏跑着跑着就闪退，有的甚至

这几天读《Ｃ＋＋编程规范》读到第３０条：“避免重载&&、||或,（逗号）”，一直不能完全吃透。今天才理解，原来是这么回事： 　　内建的&&（逻辑与）、||（逻辑或）和,（逗号）操作符总是满足以下性质：从左至右对操作数进行求值；对于&&操作符，若左操作数为假，那么右操作数将不会求值，所以我们可以放心地写下if (p && p->next)这样的代码而不用担心p为0时p->next

《Ｃ＋＋编程规范》第５１条：析构（destructor）、释放（deallocation）和交换（swap）永不失败。 　　我今天中招了。 　　今天为了做实验而写了个小程序。我在程序中对每个系统调用都进行了错误检查，一旦发现调用失败，就抛出自定义的异常；而main函数的最后会捕捉所有异常，然后向终端输出友好的错误信息。 　　谁知程序运行了四五个小时后，弹出了一个对话框，说：

在VC中使用Boost.Test的独立库时，若要使用Boost.Test自带的main函数，则必须在链接时加上/SUBSYSTEM:CONSOLE选项，否则会出现 “LINK : fatal error LNK1561: entry point must be defined” 这样的链接错误。 　　见http://boost.2283326.n4.nabble.com/test-Fata

近几年的编程中，我越来越倾向于以严格的字母顺序来安排函数在源代码中的出现顺序，比如将finalise函数的定义写在init函数定义的前面。其实这样也说不上有什么好处，只能算是一种洁癖。不过这样就会导致我经常遇到这种情况：func1和func2是两个内部函数，func1要调用func2，但是func1的定义却出现在func2的前面。此时我通常会将func2的声明写在func1的定义里，就像下面这样：staticvoidfunc1(void){ void func2(void);

A Difference between VS2008 and VS2010 on Project Dependency or ReferenceSoppose that I have two projects, denoted by A and B,  in some solution. A is an exe project referencing B, which is a dll project. In VS2008, we should set the Project Dependencies o

The Packings of struct between nvcc and g++ Are DifferentOne of my CUDA programme, which was successfully built by Visual Studio and ran on Windows without any problem, failed to produce the correct output on Mac and Linux. The error lay in the difference

A Format of Writing Initialization Lists in C++ ConstructorsI found a nice format writing initialization lists in C++ constructors today when I was reading the source code of CppUnit:MyClass::MyClass(m1, m2, ..., mn) : member1(m1) , member2(m2)

<br />用Visual C++编写DLL,如果在new project时选了MFC DLL,而后又想写成Regular DLL,即拥有自己的DllMain()入口函数,则在build时会遇到类似如下的link错误:<br /><br />error LNK2005: _DllMain@12 already defined in xxx.OBJ<br /><br />其中一种解决方案:<br /><br />你只需要在工程设置里面，把<br /><br />WIN32,NDEBUG,_WI

　　曾经有一位Java程序员对我说，他现在越来越频繁地采用构造函数+初始化函数的方式来准备一个对象，而不是直接在构造函数里将所有资源都准备好。谈及原因，他说道，他在GUI开发当中经常要在子类的初始化过程中调用父类的资源，而他发现子类的构造函数执行时，有的父类资源却还没构造好。　　我对Java的机制并未做过深入的了解。“构造函数+初始化函数”的对象准备方式似乎违反了RAII 原则。而且在C++中，当子类的构造函数开始执行时，父类的构造函数应该已经执行完毕，父类资源也应该都已经构造好了——至少我目前还没

以前曾听人说过要避免使用异常规范，而且也听说C++0x已经把异常规范去掉了。不过因为不知这里面道理何在，所以还是一直在项目中大量地使用了异常规范。目前为止倒也还没遇到过大问题，只是在跨编译器时遇到了些小麻烦：VC++虽然接受但却不会实现异常规范，因此并不会检查函数声明中的异常规范

今天阅读《深度探索C++对象模型》，得知在C之中，未初始化的全局对象“被视为一个‘临时性的定义’，因为它没有明确的初始化操作。一个‘临时性的定义’可以在程序中发生多次，那些实例会被链接器折叠起来，只留下单独一个实体”（见第197页）。于是我做了做实验，以验证书上说的话。

很多人都知道，gcc在链接静态库时是从前往后找符号。因此如果一份文件foo引用了静态库bar.a，那么在链接命令中，bar.a必须放在foo的后面，也就是像gcc ... foo ... bar.a这样；否则链接时会报找不到定义的错误（即undefined reference to ...）。如果我们在链接命令中，直接用.o文件替换.a文件，那也需要遵循gcc的这种链接顺序吗？可以用gcc .. bar.o ... foo这样的链接命令吗？可以做个简单的试验。