C++博客-n's 燃烧小宇宙

C++检查浮点类型能否转换为整型

nelson — Sun, 19 Jun 2011 08:06:00 GMT

最近尝试用Cocoa做一个四则运算计算器来练手，类似于Windows cmd: calc的那种。

毕竟这个东西算是我们项目组的入门练习，当年很多新人刚进来，老组长都会教他们用MFC/QT做个计算器来看看水平。由于各种原因，我当年倒是没有受到这种“礼遇”，等我真正开始做软件的时候，还是服务器端这样的纯C++代码做得比较多。但是不做不知道，一做才发现UI的逻辑还是挺复杂的，比如说，按“1”是追加到当前显示还是覆盖现有的显示呢，最后把逻辑弄清楚倒不是很麻烦，但要写出好看的代码还是有比较大的差距的。

以上都是前言，好像比较长……

要说的是，在这个过程中发现的问题，计算结果是浮点数，要怎么判断其是否能无损地转换成整数，从而消除小数点后的一段无用的“0”，以更好地显示。直接上代码：

1 template <typename FloatType>
2 struct _floattype_meta
3 {
4 };
5
6 template<>
7 struct _floattype_meta<float>
8 {
9     enum {
10         EXPO_OFFSET = 23,
11         EXPO_LEN = 8
12     };
13
14     typedef uint32_t match_uint_type;
15 };
16
17 template<>
18 struct _floattype_meta<double>
19 {
20     enum {
21         EXPO_OFFSET = 52,
22         EXPO_LEN = 11
23     };
24
25     typedef uint64_t match_uint_type;
26 };
27
28 template <typename FloatType>
29 struct float_to_int
30 {
31     typedef struct _floattype_meta<FloatType> _meta;
32
33     bool operator() ( FloatType f, FloatType precision )
34     {
35         static const _meta::match_uint_type EXPO_MASK =
36             (~((~(_meta::match_uint_type)0) << _meta::EXPO_LEN )) << _meta::EXPO_OFFSET;
37         _meta::match_uint_type* pf = (_meta::match_uint_type*)&f;
38         uint32_t expo = ((*pf) & EXPO_MASK) >> _meta::EXPO_OFFSET;
39
40         static const uint32_t EXPO_FIRSTBIT_MASK = 1<< (_meta::EXPO_LEN-1);
41         static const uint32_t EXPO_BOUND = EXPO_FIRSTBIT_MASK - 1;
42         if ( expo >= EXPO_BOUND )
43         {
44             uint32_t to_right_move = expo - EXPO_BOUND;
45             if ( to_right_move >= _meta::EXPO_OFFSET )
46             {
47                 return true;
48             }
49             uint32_t cmp_len = _meta::EXPO_OFFSET - to_right_move;
50             _meta::match_uint_type mask = ~(~((_meta::match_uint_type)0) << cmp_len);
51             return (*pf&mask) ? false : true;
52         }
53         else
54         {
55             return ( f < precision && f > -precision ) ? true : false;
56         }
57     }
58 };

我的方法是通过浮点型的结构来进行判断。

浮点类型一般结构如下：
|+/-| exponent | tail |
对于float，指数部分为8字节，尾数部分为23字节。

对于double，指数部分为11字节，尾数部分为52字节。
其中指数部分是采用偏移方式的，比如float的指数部分为130，偏移值为127，即实际指数为130-127。
更详细的请参考这里。

判断方法是，计算指数的值，根据偏移判断小数点后的尾数，想得比较简单，汗！
引入参数精度是为了判断值小于1时达到某个阈值的时候可以将后面的小数略去。

Honestly，其实这个应该可以用sprintf，然后判断小数点后的“0”来实现的，似乎更加简单方便。
但是我觉得，作为一个“码农”，重造轮子也是一种趣味嘛！

nelson 2011-06-19 16:06 发表评论

关于工作关系的一些吐槽

nelson — Thu, 16 Jun 2011 14:24:00 GMT

身处一个学生团队中，虽说会像公司一样从事项目研发、承包一些外包项目，学生就如公司的员工一样，老师有点像公司Boss又不完全是，但感觉最大的分别是人与人、人与集体之间关系维系的纽带不一样。

好比说在公司里，抛开兴趣爱好、对公司情感等的上层因素，人与集体之间最基本的关系是合同制、契约关系。这意味着，我完成我的工作，你就要相应地支付劳动报酬，虽然有些赤裸裸的资本主义金钱利益交易的色彩，但确是最实在、最有保证的关系。如果我完成不了我的工作，你可以少付、乃至不付劳动报酬；超额完成任务，可以有相应的奖金（理想状态下）；哪天我请假了，我没有工作，那天的工资可以扣除。好比钢炼里面的“等价交换”原则，虽则不时有些残酷，却又是最自然、最透明、最公正的。这学期由于项目原因，在外面公司待了好一段时间，看到了不少外面的人对于工作的态度也是相当的坦荡荡，该请假时就请假，迟到了就扣钱。当然，这最好还是以不影响集体利益为前提。

反观我所处环境的情况，师生之间显然不可能是雇佣关系，那是什么来维系一个团队的运作，完成一个个的项目呢？我认为是“责任”。培养成有责任感的人，也是我们所提倡的。但，我曾经听过一个过来人说的故事，某人某次小假期回家，最后几天突然生病了还比较严重，父母都劝他在家把病养好再回去做项目，他还是执意要回来，毕竟大家都在工作，他也不好意思就这样多休息几天。又如，大三那年的暑假，正值新项目开始，项目周期短、工作量大，大家都在奋战着，突然我家里发生变故，当时我想还是不要回去了，回去也没用，而且我一走，我这块的进度谁来保障，就还是留在学校赶项目，后来回想起来还是有些遗憾。我们这些人总在莫名其妙中对集体担负着这样那样的“责任”，虽然这样的责任意识长期保持着会让我们成为很不一样的人，但是与此同时我们也是活得很累的人。

我觉得，一切以集体为重的责任意识很容易淹没了个性的存在，很多个人化的事情也因次而难以开展。由于我们的关系是抽象化的“责任”而不是更为具体的“合同”，很多事情还真是到了说不清的地步。考试、学生自然或不自然地便围绕着集体的项目来安排，有些很私人化的事情不好去做。最疲累的是不自觉无时无刻关注着这样的“责任”关系、并以一种较为“癫狂”的方式来履行。作为一个“全职”人员，朝九晚十是平常事，但有时候我觉得待不住了、坐得快要吐了，我觉得我还是不能离开，因为集体还要运作，或者说个人的不合作很容易弱化集体的凝聚力（不否认这是我写这篇文章的原因）。

另一方面，以“责任”为纽带来带领集体，总有些异样的感觉。曾经也做到了类似项目组长之类的工作，需要管理一部分人，但总感觉在这个过程中没有什么有说服力的关系来调度手下的人。如果是合同关系下的工作，你不情我不愿，可以走可以换人，大家都乐得轻松。金钱利益是必须的，但总可以换种方式来获取它。但是换着以“责任”意识作基础，手下的人没有这个意识似乎工作都不用做了，又或者所做的不是个人所希望得到的，作为管理者我也不能给你什么、保证些什么。

好吧，写到这里，我觉得我想描述的是一个很浓厚的“胶合层”，但以“责任”来概括似乎已经不够全面了。但依据《Unix编程艺术》，太厚的胶着层不是一种好的设计方式。简洁、透明、直接的会是更好的方式，工作也能够更好地开展。

幸好还是有终极的个人保障机制——you can quit！离开集体，便彻底脱离这种千丝万缕的关系。

不说太多，仅此吐槽！

nelson 2011-06-16 22:24 发表评论

Archlinux编译ACE时出的问题

nelson — Sat, 15 Jan 2011 09:08:00 GMT

官方有个比较精简的编译安装指南，见这里。但是对于我所碰到的问题没有说明

提示链接时SSL的符号没有找到，但我是装好了openssl的，也特意找了一下，都安装在/usr/下

然后翻看了一下build/examples/IPC_SAP/SSL_SAP/下的Makefile，找到“LIBS = -lrt -ldl”，没有指明openssl库的链接

遂加上！～

LIBS = -lrt -ldl -lssl

编译之！～

build/test/SSL的问题同解。

不知道其他Linux发行版有没有这样的问题，还是我的配置有问题，但总算最终编译完了。

nelson 2011-01-15 17:08 发表评论

Python做Web的中文编码问题

nelson — Wed, 06 Oct 2010 07:50:00 GMT

摘要: 阅读全文

nelson 2010-10-06 15:50 发表评论

new/delete operator笔记

nelson — Mon, 19 Jul 2010 10:21:00 GMT

1.new操作符可以带多参数
2.没有对应的operator delete会出现warning（vs2008）
3.operator new/delete是类成员的情况下，用自定义的operator new创建、调用构造函数，会自动调对应的operator delete来析构
4.delete操作符可以带多参数，要使用自定义的operator new只能显式调用
5.自定义的operator delete不会自动析构对象

nelson 2010-07-19 18:21 发表评论

关于vs2008 SP1中CMFCToolBar的一些事儿

nelson — Thu, 20 May 2010 15:53:00 GMT

话说昨天解决了MFC跨线程操作控件的问题，我满以为今天可以free一回，玩玩Linux、学学Vim、再准备一下毕业论文的事情，但还是有事情要做，然后又是“被”MFC郁闷了一天。

先介绍一下总体的情况。我们项目客户端的开发环境是VS2008+SP1，用的是MFC类库，里面居然用到了CMFCToolBar、CMFCMenuBar以及Appearance变化等的SPI新特性。说“居然”是因为这些东西不是项目必要的，当时可能也以为只是名字变了用法没变，估计在工程创建的时候根本就没有考虑这些，直接按着单文档工程默认配置，next、next直接创建完的，囧！当时做的时候也只是当作测试Demo来用，也没太在意，毕竟我们项目的重点在服务器而非这个MFC客户端。

后来由于项目原因，甲方要求我们把这个客户端尽快修改成一个可以发布版本。不改不知道，一改吓一跳，当准备动手修改工具栏时才发现与以前惯的CToolBar真实差距甚大。CToolBar可以用CImageList把自定义的BMP图片放到工具栏的按钮，详细可看这里，CMFCToolBar根本就不是这样的一个玩法。直接放一个CToolBar上来，在DockControlBar()的时候会出现断言错误（缺少DockBar，貌似是这个名字，汗！）。定位代码到MainFrm的EnableDocking()，现在的MainFrm的继承关系是CMainFrm->CFrameWndEx->CFrameWnd，而以前是CMainFrm->CFrameWnd，CFrameWndEx::EnableDocking()是为DockPane()服务的，而DockControlBar()需要的DockBar并不会被初始化。调用基类的CFrameWnd::EnableDocking()后再DockControlBar()不会出现断言，但是那个工具栏没有显示。而且现在新特性下在工具栏位置能够按出右键菜单，但右键菜单中根本不可能有关于该CToolBar的信息，乍看起来很不和谐~

最后，求助本地MSDN无果，貌似SP1没有包含对MSDN文档的更新；求助MSDN官网，那个真是“言简意赅”。只能说，MS你这次真的“亮”了！

以下为google + vs2008 sp1 sample + 看代码的成果：

创建默认ToolBar外的第二个ToolBar

注意，Wizard生成的工具栏Create时没有带ID，但第二个工具栏Create时最好要带ID。加了ID之后，在工具栏右键菜单才会出现第二个工具栏的CheckBox。否则，不良后果有：1、右键菜单没有该工具栏Checkbox；2、把默认工具栏和该工具栏拖出来（浮动），可以看到名字都是一样的（英文版为Standard）；3、后面要提到的UserImage不能作为按钮图标显示。

加载工具栏资源

我们先来看看CMFCToolBar加载工具栏的函数原型：

1 virtual BOOL LoadToolBar(UINT uiResID, UINT uiColdResID = 0, UINT uiMenuResID = 0, BOOL bLocked = FALSE,
2 UINT uiDisabledResID = 0, UINT uiMenuDisabledResID = 0, UINT uiHotResID = 0);

可以看出，uiResID代表要加载的工具栏资源，理论上只需要这一个参数就能完成工具栏的加载。但是VS的Toolbar Editor只能编辑4bit的工具栏图标，以前CToolBar是用CImagList来加载更多bits的图标的，现在应该怎么做呢？多亏了Explore sample的例子，我发现后面的几个UINT参数就是BMP的资源，最主要的是最后一个uiHotResID，即便其他用默认值，这项赋BMP ID就能按预期的图标显示。Cold、Disable表示的是不同状态下的图标样式，带Menu的是Menu有关的图标，具体可看SP1 Feature的sample。
我的Demo里自定义工具栏的总创建过程：

1     if ( !m_mybar.CreateEx(this, TBSTYLE_FLAT,
2                            WS_CHILD | WS_VISIBLE | CBRS_TOP | CBRS_GRIPPER | CBRS_TOOLTIPS | CBRS_FLYBY | CBRS_SIZE_DYNAMIC,
3                            CRect(1,1,1,1), ID_MYBAR) ||
4          !m_mybar.LoadToolBar( IDR_TOOLBAR1, 0, 0, FALSE, 0, 0, theApp.m_bHiColorIcons?IDB_BITMAP1:0 ) )
5     {
6         TRACE0("Failed to create toolbar\n");
7         return -1;      // fail to create
8     }
9     m_mybar.SetWindowText(_T("abc"));

最后的SetWindowText()设置工具栏的名称。
CMFCToolBar有LoadBitmap的方法，但是测试发现，用LoadToolBar只加载工具栏资源，再用LoadBitmap加载BMP资源，虽然返回值是TRUE，但显示图标为空白，没有实际效果。

工具栏停靠

1 // TODO: Delete these five lines if you don't want the toolbar and menubar to be dockable
2   m_wndMenuBar.EnableDocking(CBRS_ALIGN_ANY);
3   m_wndToolBar.EnableDocking(CBRS_ALIGN_ANY);
4   m_mybar.EnableDocking(CBRS_ALIGN_ANY);
5   EnableDocking(CBRS_ALIGN_ANY);
6   DockPane(&m_wndMenuBar);
7   DockPane(&m_wndToolBar);
8   DockPane(&m_mybar);

与默认工具栏无异。

用户自定义图标

CMFCToolBar可以让用户自定义工具栏图标，使用静态成员函数SetUserImages()将一个CMFCToolBarImages对象设置进去，由所有CMFCToolBar对象共享。Wizard自动生成代码中有这样的例子：

1     if (CMFCToolBar::GetUserImages() == NULL)
2     {
3         // load user-defined toolbar images
4         if (m_UserImages.Load(_T(".\\UserImages.bmp")))
5         {
6             m_UserImages.SetImageSize(CSize(16, 16), FALSE);
7             CMFCToolBar::SetSizes(CSize(16,16), CSize(16,16));
8             CMFCToolBar::SetUserImages(&m_UserImages);
9         }
10     }

这个例子加载了工程路径下的一个BMP，其他方法可以查看MSDN，与CImageList有点点类似。
使用CMFCToolBar::ReplaceButton()可以替换已有的工具栏按钮，以下是我的Demo中的代码：

1 m_mybar.ReplaceButton( ID_QTLOGO, CMFCToolBarButton(ID_QTLOGO, 0, _T("123"), TRUE) );

第一个参数ID_QTLOGO为自定义工具栏上的一个按钮，后面是一个CMFCToolBarButton的临时对象。CMFCToolBarButton构造函数第一个参数为替换后的ID，第三个参数为名称，第二个参数为图标的索引(zero-based)，第四个参数为m_bUserButton，指明第二个参数是索引工具栏已加载图标(LoadToolBar或LoadBitmap)还是用户自定义图标（SetuserImages），TRUE指用户自定义图标。这里的结果是将ID_QTLOGO上的图标替换为UserImages.bmp上的第一个图标。

GetCmdMgr()->GetCmdImage()可以根据工具栏上图标的ID获取出已加载图标的索引值：

1 m_mybar.ReplaceButton( ID_QTLOGO, CMFCToolBarButton(ID_QTLOGO, GetCmdMgr()->GetCmdImage(ID_PLUS), _T("123")) );

这里将工具栏上ID_QTLOGO的图标替换为ID_PLUS按钮对应的图标。

特别地，如果在你将这些工具栏改来改去但显示结果却没有改变的时候，你可以尝试删除 HKEY_CURRENT_USER\Software\Local AppWizard-Generated Applications\$(你的程序名) 这个键值，当你重启程序后工具栏应该会按你的预想变化的。这是我在查资料时看到的，当时没注意但后来发现挺有用的，出处没有记录下来。

最后，ReplaceButton还可以将按钮替换为其他控件。

其他...

我在自定义工具栏上做了一个有效响应，里面使用静态成员函数CMFCToolBar::ResetAllImages()将所有图标都清空了，此时会发现默认工具栏、自定义工具栏的图标都为空。

1 void CMainFrame::OnQtLogo()
2 {
3     CMFCToolBar::ResetAllImages();
4
5     //CMFCToolBar::AddToolBarForImageCollection(IDR_MENU_IMAGES, theApp.m_bHiColorIcons ? IDB_MENU_IMAGES_24 : 0);
6
7     m_wndToolBar.LoadBitmap(IDB_BITMAP1);
8     m_mybar.LoadBitmap(IDR_MAINFRAME_256);
9     m_wndToolBar.RedrawWindow();
10     m_mybar.RedrawWindow();
11 }

更奇妙的是，后面我对两个工具栏重新加载了BMP，而且加载的BMP资源是反了的，此时默认工具栏上出现了原来自定义工具栏的4个图标，余下部分及自定义工具栏则为原来默认工具栏图标。可以想象，RestAllImages只是将图标资源都释放了，工具栏资源依然健在，重新加载BMP的时候，工具栏图标就像一个个顺序排好的空间，加载进来的BMP图标会出现从前往后补位的现象。
注意代码中，默认工具栏图标重新加载时使用的资源是IDR_MAINFRAME_256，是默认的工具栏资源。也就是说，这里用LoadBitmap加载工具栏资源也是有效果的。这样应该可以说明工具栏在创建时LoadToolBar、LoadBitmap分别成功地加载了工具栏、BMP资源，实际上是加载了两套图标资源，这两者是顺序而非重合的，所以只显示原来的工具栏资源。要想指定两者的重合关系，只有在LoadToolBar的时候同时传入工具栏资源及BMP资源的ID。

Demo下载

————————————————————————————————————————————————————————————————
好吧，终于写完了！写得很仓促，不足的地方也很多，欢迎指教！

nelson 2010-05-20 23:53 发表评论

最近几天被MFC折腾~

nelson — Wed, 19 May 2010 15:22:00 GMT

备注：Rimi是我们用的一个分布式机制。

在进行设备树（也就是一个CTreeCtrl控件）更新修改的时候，遇到了一个比较bug的问题。

为了提供更好的用户体验，甲方希望设备树更新之后滚动条位置能够保持与更新前一致。设备树的更新过程是这样的：更新消息来自Rimi的通知机制，类似于函数回调，客户端在收到消息之后调用Rimi的对象方法来获取新的设备树信息，然后更新树。乍看之下，要完成这个修改好像很简单，只要更新前先记录滚动条的滚动位置，更新后还原位置，如果更新后滚动条滚动范围变化了还要微调一下位置，逻辑上来讲就这么几个步骤。

我一开始也是按照这样的思路，GetScrollPos()获取当前滚动条的滚动位置，然后更新树（先删除所有节点再逐个添加，其他省略...），GetScrollRange()获得新的滚动范围，最后SetScrollPos()将旧的位置与滚动范围最大值中最小的一个设回去（这里用到的ScrollBar是CTreeCtrl自动产生的，注意不是两个控件，这里调用的函数都是CTreeCtrl的方法）。但实际效果是，树更新后滚动条滚到准确的位置，但树的视图到了最顶，点击一下滚动条的那个方块才能回到之前的位置。也就是说，滚动位置的更新与树的视图分离了。

之后，我一直以为是我控件的方法用错了，对着MSDN和CSDN纠结了很久。最后忍无可忍，自己写了个测试Demo，里面就一Dialog，一CTreeCTrl，树上随便加了些东西，然后又一按键，按键后会重新刷新树，再滚动到原来的位置，结果居然是对的，视图跟着滚动条的位置变化了。为了更好的模拟设备树节点增删的效果，我在按键响应上又作了处理，按一下重刷树的时候会隐藏几个节点，再按一下这些节点显示出来，滚动位置按照客户端里面的一个处理方法，结果居然也是正确的。问题变得玄乎了！

无意间发现客户端里面有个手动刷新设备树的快捷键，估计是当年pb做调试的时候留下来的。快捷键的响应直接调用更新树的函数，重刷后的显示出人意料地是对的。比较一下两种更新方式的过程：

Rimi：通知到来—>更新树（Rimi回调函数，Rimi自己维护了一个线程池，远程调用在被调用端的发起者都是Rimi自己的线程）
快捷键：按键响应—>更新树（MFC消息处理函数）

更新树所用到的是同一个函数，但调用者却是不同的。因为Rimi用了boost::function，那我也在按键响应的时候对要调的函数用function来包装一下，造成两者在调用栈上调用的函数、顺序大部分是一致的，只有最底层不同，一边是Rimi，一边是MFC消息传递。

后来jianhao说，以前在Rimi的回调函数里面调Rimi对象的方法出过问题，然后我又顺道回忆起之前zxb在Rimi函数（还是对象方法）里面调system()也有问题。

难道说Rimi线程就是“万恶之源”？好吧，我把更新代码移到另外一个线程里面，Rimi回调的时候唤醒更新线程，更新后视图还是不能跟着滚动位置变；将快捷键的响应也修改一下，自己不作更新，也是唤醒更新线程，这个方法也变得不灵了，囧！这可以说明问题跟Rimi线程无关。

难道说线程调用才是“万恶之源”？把之前做的那个Demo小改了一把，线程做刷新，按键响应只唤醒更新线程，果然不灵了！上网google了一把，关键字“mfc 线程操作控件”，首先映入眼帘的是《MFC中跨线程操作控件会不会出现像C#中的异常问题?》。这时候我也不关心这个帖子的内容了，线程操作控件有异常是吧，那就不用线程做咯！这时候我才回想起WIN32里面有自定义消息这玩意，MFC里面给定一个消息ID，ON_MESSAGE绑定一个处理函数，PostMessage或SendMessage来发消息，然后由WIN32自己的消息循环来调用处理函数，这样应该是可以保证用非Rimi线程来更新设备树的。再一次把Demo小改了一把，按键响应Post一个自定义消息，消息处理函数做刷新，结果是对的；再改，按键响应唤醒线程，线程里面Post自定义消息，结果也是对的。

原以为是控件使用问题，又以为是Rimi不兼容问题，最后实质为MFC跨线程使用控件的问题。其实我也不清楚这是不是真正的问题，毕竟我MFC既不懂又用得少。That's all!

最后附上我的测试代码
http://www.cppblog.com/Files/neverwinter/testtree.rar

nelson 2010-05-19 23:22 发表评论

对象自杀

nelson — Mon, 26 Oct 2009 13:29:00 GMT

最近做项目写代码遇到了对象自杀的问题。

第一个是自己设计的，对象持有定时器，自己维护生命周期。

第二个是无意中遇到的，由于采用boost的线程库，将成员函数变为线程用，最后在一堆调用之后居然把自己杀掉了。

很不幸的是，在过程中都遇到了相同的问题——堆栈挂掉了。

然后一轮定位，居然都是boost mutex的问题，scoped_lock很容易让人放松警惕。

void XXX()
{
    boost::recuisive_mutex::scoped_lock lk(m_mutex);



    YYYY();


}

void YYY()
{


    delete p;// 释放XXX所在对象


}

作为类成员的mutex没有被解锁，然后所在的类就被释放了，这就造成了堆栈挂掉。

对象自杀显然不是一种很好的风格，还是尽量避免吧！

nelson 2009-10-26 21:29 发表评论

项目之苦

nelson — Sat, 19 Sep 2009 04:54:00 GMT

此文章涉嫌各种敏感，已被博主删除~

nelson 2009-09-19 12:54 发表评论

fstream改写文件

nelson — Mon, 14 Sep 2009 06:40:00 GMT

项目中有这样的需求：
1.给一个一定大小的空文件改写内容；
2.不能改变该空文件的大小。

一开始是用ofstream做的，但是每次一打开文件，原来的空文件的大小就改变了。之后用app方式打开，但是每次的新数据都是追加到文件尾部，seekp无论如何不能到达实际文件的首部，这样文件大小就变了，不符合需求2。

后来发现用fstream，采用in | out的方式来打开，终于可以安全地改写文件了。

nelson 2009-09-14 14:40 发表评论