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

boost的bjam编译指令

酿妹汁 — Sun, 30 Jan 2011 01:34:00 GMT

前面必须使用到的，类似下面的指令
F:\sdk\boost>bjam --link=static --threading=multi --runtime-link=shared debug release stage

后面需要选择编译器和要编译的库
--toolset=msvc-9.0 --with-date_time --with-thread......

酿妹汁 2011-01-30 09:34 发表评论

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 发表评论

用cmake生成ogre1.7rc的项目文件，哇擦泪......

酿妹汁 — Tue, 12 Oct 2010 10:59:00 GMT

记录一下这个，容易忘记的DXSDK_DIR环境变量，可以在cmake里添加dx的sdk路径，否则找死也找不到rendersystem_direct3d的项目文件。

酿妹汁 2010-10-12 18:59 发表评论

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

酿妹汁 — 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 发表评论

异常处理的可恶陷阱

酿妹汁 — 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 发表评论

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 发表评论

DLL的共享测试

酿妹汁 — Sat, 27 Jun 2009 15:04:00 GMT

今天稍微实验了一下DLL的数据共享问题，做了两种情况下的测试，第一种是两个进程同时调用一个DLL的实验，另一种是一个进程调用一个两个DLL，然后这两个DLL有依赖关系，记录一下得到的测试结果。

当一个进程调用LoadLibrary、LoadLibraryEx以及FreeLibrary时，DllMain会被调用，从DllMain的入口函数的第二个参数可以得知是加载还是释放。LoadLibraryEx的flag参数传入DONT_RESOLVE_DLL_REFERENCES可以跳过DllMain的调用，这在很多时候是有用的。
当一个进程在调用LoadLibrary后又启动了线程，则每启动一个线程，就会调用一次DllMain，同样可以从DllMain的第二个参数的值来区分调用时由进程引起的还是由线程引起的。第二个参数的值一般有4种，如下：
DLL_PROCESS_ATTACH
DLL_PROCESS_DETACH
DLL_THREAD_ATTACH
DLL_THREAD_DETACH
不用解释也能看得出来分别是表示什么意义了，通过这个可以选择性的对DLL中的数据进行初始化。
如果是两个进程同时调用一个DLL的话，数据是不会共享的，除非你设置了seg项为共享，具体不同的编译器会有不同的设置方法。两个进程对同一个DLL的调用计数也是分开的，这让我很放心了，之前一直害怕的冲突问题释然。

当一个进程去调用一个DLL甲，而甲又在初始化的时候调用了DLL乙，进程通过甲的函数来访问了DLL乙，同时自己也亲自调用了DLL乙并取出和更改了数据。这样的情况下，DLL乙的引用计数是共享的，数据也是共享的，加载和释放都很安全，之前担心DLL乙中的单件会被重复调用的情况也不可能存在了。

酿妹汁 2009-06-27 23:04 发表评论

MySQL的备忘录

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

首先安装完MySQL5.1.30后，可以进入控制台，输入 mysql -u root -p然后回车，如果没有密码的话，-p似乎就能省掉了。
进入后输入 show databases命令就可以看到所有的数据库了。
然后是新用户的问题，如果你想添加一个新的用户，有很下列三种方法：
1、直接在mysql数据库中的user表里直接insert，但是很麻烦
2、使用GRANT [权限] ON *.* TO [username]@[客户端地址] identified by [password] 这样的命令，具体可以看文档
3、使用CREATE USER [用户名] 这样的命令创建用户
这里要注意的是，第二种方法创建用户的话，必须带有密码，如果你想创建无密码用户的话，则必须用第3种方法。
最后就是给用户权限的问题，一般都使用GRANT语句，具体可参考文档，不过你也可以直接对db表直接进行修改和添加，只要你不怕麻烦。

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