C++博客-n's 燃烧小宇宙-随笔分类-C++

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

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

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

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

数组引用作函数模板的思考

nelson — Mon, 14 Sep 2009 04:26:00 GMT

1 #include <iostream>
2 using namespace std;
3
4 void RefAsParam(int (&aRR)[5])
5 {
6     cout << aRR[3] << endl;
7 }
8
9 template < size_t SZ >
10 void RefAsParamT(int (&aRR)[SZ])
11 {
12     cout << aRR[0] << endl;
13 }
14
15 void main()
16 {
17     int a[5] = { 1, 2, 3, 4, 5};
18
19     RefAsParam( a );
20
21     RefAsParamT( a );
22
23     getchar();
24 }

这个是上次在某blog友回帖时有感写的一个例子程序。

现在把目光放在RefAsParamT函数，采用非类型模板的方式使数组引用作为入参，乍看好像很爽，不需要在函数定义时指定数组的大小，比非模板方式的RefAsParam有极大的通用性。

但是，从模板生成的角度来看，对于不同的SZ就会产生不同的RefAsParamT函数，效率上说不过去，虽说这些代码是编译器代替人手写的。

再从数组引用作为入参的角度看，个人认为数组引用左入参的意义不大，特别是对于动态分配（new）的数组，这两个函数都无效。

最后，STL中先闭后开的方式来指定数组范围，这样的通用性和效率都比较好。

以上，个人愚见！

nelson 2009-09-14 12:26 发表评论

ptime转换问题

nelson — Thu, 10 Sep 2009 07:30:00 GMT

1 #include <boost/date_time/posix_time/posix_time.hpp>
2 #include <boost/date_time/gregorian/gregorian.hpp>
3 #include <iostream>
4 #include <stdint.h>
5
6 int main()
7 {
8     using namespace boost::posix_time;
9     using namespace boost::gregorian;
10
11     ptime ptNow( second_clock::local_time() );
12     std::cout << to_simple_string( ptNow ) << std::endl;
13
14     tm tm1 = to_tm( ptNow );
15     time_t tt = mktime( &tm1 );
16
17     tm* tm2 = localtime( &tt );
18
19     ptime ptt = from_time_t( tt );
20     ptime pttm = ptime_from_tm( tm1 );
21     std::cout << to_simple_string( ptt ) << "\n" << to_simple_string( pttm ) << std::endl;
22
23     return 0;
24 }

输出结果：
2009-Sep-10 15:24:10
2009-Sep-10 07:24:10
2009-Sep-10 15:24:10

第一个为ptime获得的当前时间的输出。
第三个为ptime转为tm，再tm转成ptime的输出
第二个为那个tm转成time_t，time_t再转回ptime的输出。

从结果看，第二个输出的时间很诡异上居然差了8个小时，难道是UTC时间？但boost doc那里没有这个说明，只是说用from_time_t可以将time_t转成ptime。程序中间将time_t用localtime转回tm作验证，结果是正确的。

诡异了……

nelson 2009-09-10 15:30 发表评论

拷贝构造函数与赋值操作符重载

nelson — Tue, 08 Sep 2009 08:23:00 GMT

1 #include <iostream>
2 #include <string>
3
4 class A
5 {
6 public:
7     A( const std::string &str )
8     {
9         m_szS = str;
10     }
11
12     A( const A &rhs )
13     {
14         m_szS = rhs.m_szS;
15     }
16
17     A& operator= ( const A &rhs )
18     {
19         if ( this == &rhs )
20         {
21             return *this;
22         }
23
24         m_szS = rhs.m_szS;
25         return *this;
26     }
27
28     std::string m_szS;
29 };
30
31 int main()
32 {
33     //!< 带参数基本构造，非explicit
34     A a1("SB");
35
36     //!< 不能通过基本构造完成，实质上调用的是对a1的拷贝构造
37     A a2 = a1;
38
39     //!< 验证赋值操作符
40     A a3("SC");
41     a3 = a1; // here
42
43     return 0;
44 }
45

总结：
1.实例化一个对象的时候，如果用另一个已有对象对其进行赋值，实质上调用的是拷贝构造函数，如上述的a2。
2.对一个已实例化对象采用赋值操作符对其进行赋值，调用的是赋值操作符重载的函数，如a3。

写得有点仓促，如有不同意见，欢迎拍板！

nelson 2009-09-08 16:23 发表评论

自己写的一个智能指针

nelson — Fri, 21 Aug 2009 05:00:00 GMT

以下为智能指针的demo。
设计思路为：通过一个引用计数的指针在多个auto_ptr中共享Type对象。

1 // auto_ptr.h
2 #include <iostream>
3 namespace myspace
4 {
5 template <class T>
6 class auto_ptr
7 {
8     T *t; // 指针对象
9     size_t *use; // 引用计数，采用指针的方式是为了方便多个auto_ptr的共享
10 public:
11     //!< 一般构造函数
12     auto_ptr(T *obj)
13     : t(obj) // 接收指针
14     , use(new size_t(1)) // 创建引用计数
15     {
16     }
17     //!< 拷贝构造函数
18     auto_ptr(const auto_ptr<T> &ptr)
19     : t(ptr.t)
20     , use(ptr.use)
21     {
22         ++*(ptr.use); // 传递引用计数后，计数值+1
23     }
24     ~auto_ptr()
25     {
26         // 每次析构的时候，如果计数值为0则删除对象
27         if (--*use == 0)
28         {
29             delete t;
30             delete use;
31         }
32     }
33     //!< ->操作符重载
34     T* operator-> () const
35     {
36         return t;
37     }
38     //!< *操作符重载，返回指针对象的引用
39     T& operator* () const
40     {
41         return *t;
42     }
43 };
44
45 //!< 流输出，采用了*操作符，所以不需要设为friend
46 template <class Type>
47 std::ostream& operator<< (std::ostream &os, auto_ptr<Type> ptr)
48 {
49     os << *ptr;
50     return os;
51 }
52 }//end of myspace
53
54 // main.cpp
55 #include <iostream>
56 #include "auto_ptr.h"
57 #ifdef _DEBUG
58 #define new new (_NORMAL_BLOCK, __FILE__, __LINE__)
59 #endif
60 int main(int argc, _TCHAR* argv[])
61 {
62     myspace::auto_ptr<int> iptr(new int(9)) ;
63     std::cout << iptr << std::endl;
64     ++ *iptr;
65     std::cout << iptr << std::endl;
66     (*iptr) --;
67     std::cout << iptr << std::endl;
68     getchar();
69     return 0;
70 }
71

从上面的Demo中，可以看到这个智能指针的缺点：
每次创建智能指针的时候，传入的指针是对外暴露的，采用new的方式作为入参才能保证安全的。如果这个new出来的对象（如上面的int（9））在别处被delete了，继续使用这个智能指针相当于使用一个野指针。这样的问题即便是boost的share_ptr也是会有的。

nelson 2009-08-21 13:00 发表评论

Member Initialization list（成员初始化表）

nelson — Wed, 19 Aug 2009 04:26:00 GMT

    这个是我们组的每日一例，主要目的是想通过老队员指导新队员，同时又可以巩固大家的cpp知识。我们组长说，项目做完之后这些东东可以整理出书了～
    这一份是我写的，所以就发布出来啦！～这个还算写得比较详细吧！

Chapter One - 调用构造函数对成员变量进行构造、初始化

    在类构造的时候，对于类成员变量的构造貌似可以在构造函数中完成，那为什么还需要成员初始化表呢？
    我们来看看这样的情况：

1 /* programme 1 */
2 class Base
3 {
4 public:
5     Base(int val)
6     : i(val) //这里为什么要放在成员初始化表呢？
7     {
8      //i = val??
9     }
10     ~Base(){}
11
12 private:
13     int i;
14 };
15
16 class UseBase
17 {
18     Base b;
19 public:
20     UseBase(){} //没有用Base的构造函数
21     ~UseBase(){}
22 };
23
24 int main()
25 {
26     return 0;
27 };
28 /* end of programme 1 */

程序出现这样的错误：error C2512: 'Base' : no appropriate default constructor available，在UseBase中Base没有被合理地初始化。

1 /* programme 2 */
2
3 //
4
5 class UseBase
6 {
7     Base b;
8 public:
9     UseBase() : b(0){} //可以编译通过
10     ~UseBase(){}
11 };
12
13 //
14
15 /* end of programme 2 */

由此可以看出成员初始化列表的一个要点，调用构造函数对成员变量进行构造、初始化。对于内置成员变量(int、double等等，个人理解为C语言中就已经有的类型，详细信息参见Primer)而言没有明显的问题，但对于非内置成员变量而言，即便编程者没有在成员初始化表中显示调用构造函数，编译器也会隐式地调用默认构造函数。所谓“默认构造函数”就是指"$classname$(void)"这样的形式。上面的例子就是因为这个原因而编译失败的，Base没有提供默认构造函数。也就是说，需要特殊构造的类必须在成员初始化列表进行构造、初始化。

而如果有默认构造函数，是否就可以在成员初始化表中置之不理呢？答案是否定的，这涉及到效率问题。（以下程序可以中的Base完全可以用string类型来取代，但为了方便调试方式查看，所以重新编写了Base。）

1 /* programme 3 */
2
3 class Base
4 {
5 public:
6     Base(void)
7     : i(0)
8     {
9     // breakpoint 1
10     }
11     // 赋值操作符重载
12     Base& operator= ( const int val )
13     {
14         i = val;// breakpoint 2
15         return *this;
16     }
17
18     ~Base(){}
19
20 private:
21     int i;
22 };
23 class UseBase
24 {
25     Base b;
26 public:
27     UseBase()
28     //: b(0)
29     {
30         b = 3;// breakpoint 3
31     }
32     ~UseBase(){}
33 };
34
35 int main()
36 {
37     UseBase ub;
38     return 0;
39 };
40 /* end of programme 3 */

breakpoint的顺序为1-3-2，这说明UseBase中的Base既进行了默认构造，之后又进行了赋值，原本可以通过一个构造函数完成的操作，现在分成了两个步骤，效率降低了。

Chapter Two - 派生类的成员初始化表

在派生类的成员初始化表中，可以调用基类的构造函数来初始化其基类成分。

1 /* programme 4 */
2 #include <iostream>
3 using namespace std;
4 class Base
5 {
6 public:
7     Base( const int val )
8     : i(val)
9     {
10     }
11
12     Base& operator= ( const int val )
13     {
14         i = val;
15         return *this;
16     }
17
18     virtual ~Base(){}
19
20     void print() const
21     {
22         cout << "val: " << i << endl;
23     }
24
25 private:
26     int i;
27 };
28
29 class Derived : public Base
30 {
31 public:
32     Derived( const int val )
33     : Base(val)
34     {}
35 };
36
37 int main()
38 {
39     Derived d(1);
40     d.print();
41     getchar();
42     return 0;
43 };
44 /* end of programme 4 */

一个小错误，很多人可能会犯的：

1 /* programme 5 */
2 //
3
4 class Derived : public Base
5 {
6 public:
7     Derived( const int val )
8     //: Base(val)
9     {
10         Base(val);
11     }
12 };
13
14 //
15 /* end of programme 5 */

在构造函数体内直接调用基类的构造函数，但这样是不能完成对基类成分的初始化的。这个语句的意义是创建一个临时的Base对象。

Chapter Three - 初始化const、引用成员

利用成员初始化表能够初始化const、引用成员，这在构造函数体内是无法做到的。因为一般情况下，const、引用的对象在声明的时候就要同时将值或对象绑定到一起。

1 /* programme 6 */
2 #include <iostream>
3 #include <string>
4 using namespace std;
5 class dummy
6 {
7     const int ci;
8     string& szStr;
9
10 public:
11     dummy(const int i, string &sz)
12     : ci(i)
13     , szStr(sz)
14     {}
15
16     void printi()
17     {
18         cout << "const int: " << ci << endl;
19     }
20
21     void printsz()
22     {
23         cout << "string&: " << szStr << endl;
24     }
25
26     void setsz(string &sz)
27     {
28         szStr = sz;
29     }
30 };
31
32 int main()
33 {
34     string _4ref("hello");
35     dummy d(10, _4ref);
36     d.printi();
37     d.printsz();
38     cout << endl;
39     d.setsz( string("goodbye") );
40     d.printsz();
41     cout << "_4ref: " << _4ref << endl;
42     getchar();
43     return 0;
44 };
45 /* end of programme 6 */

输出结果
const int: 10
string&: hello

string&: goodbye
_4ref: goodbye

nelson 2009-08-19 12:26 发表评论

一个“过度设计”的四则运算器

nelson — Tue, 18 Aug 2009 15:01:00 GMT

看了Primer的TextQuery的例子，又动手copy了一遍，对于这样华丽的设计激动得久久不能自已。

前几天，按照这个例子，自己封装了一套四则运算表达式类，重现了一下这样的设计模式。

然后，做了一个parser来解析表达式，不过做得很搓，stringstream对于括号的读取有问题……不过主要功能已经基本实现了。

现上传代码：
http://www.cppblog.com/Files/neverwinter/Expression.zip

环境是vs2008 SP1，里面用到了boost的shared_ptr。

parser的设计实在太烂，如果有什么高见请指教一下！～

PS：看到别人用boost::spirit来做同样的表达式分析计算，居然80多行代码就完美实现了（还包括提示信息）。可见，boost的潜力是十分大的，以后一定要好好学习、挖掘一下。

nelson 2009-08-18 23:01 发表评论