C++博客-
一年十二月谁主春秋
-随笔分类-C/C++

使用CString GetBuffer自适应获取计算机名称

春秋十二月 — Wed, 31 Jul 2019 04:51:00 GMT

为了减少程序中的硬编码，灵活按需管理字符串空间，使用了ATL中的CString类，代码如下

1 CString bstrComPathName;
2         WCHAR componentPathName[1];
3         DWORD dwNameLen = 1;
4
5         if (!GetComputerNameEx(ComputerNamePhysicalDnsFullyQualified, componentPathName, &dwNameLen))
6         {
7             DWORD dwErr = GetLastError();
8             if(ERROR_MORE_DATA==dwErr)
9             {
10                 if (!GetComputerNameEx(ComputerNamePhysicalDnsFullyQualified, bstrComPathName.GetBuffer(dwNameLen), &dwNameLen))
11                 {
12                     zlog_error(g_zc, "GetComputerNameEx with ComputerNamePhysicalDnsFullyQualified fail: %d", GetLastError());
13                     return -1;
14                 }
15             }
16             else
17             {
18                 zlog_error(g_zc, "GetComputerNameEx with ComputerNamePhysicalDnsFullyQualified for fail: %d", dwErr);
19                 return -1;
20             }
21         }
22         bstrComPathName.ReleaseBuffer();

需要注意的是，GetBuffer方法虽提供方便了直接修改CString对象的内部缓冲区，但违背了面向对象设计的原则（由公开方法修改内部数据），因此不保证对象的完整性，在操作完成后一定要调用ReleaseBuffer

春秋十二月 2019-07-31 12:51 发表评论

一种使用函数指针实现状态机的方法

春秋十二月 — Thu, 05 May 2016 01:46:00 GMT

结构定义

1 struct state_machine {
2     int state;
3
4 };
5
6 enum {
7     s1,
8     s2,
9
10     sn
11 };

假设s1为初始状态，状态变迁为s1->s2->...->sn。

常规实现
状态机处理函数state_machine_handle通常在一个循环内或被事件驱动框架调用，输入data会随时序变化，从而引起状态的变迁，伪代码框架如下。

1void handle_s1(struct state_machine *sm, void *data)
2{
3    //do something about state 1
4    if(is_satisfy_s2(data))
5        sm->state = s2;
6}
7
8void handle_s2(struct state_machine *sm, void *data)
9{
10    //do something about state 2
11    if(is_satisfy_s3(data))
12        sm->state = s3;
13}
14
15void handle_sn_1(struct state_machine *sm, void *data)
16{
17    //do something about state n-1
18    if(is_satisfy_sn(data))
19        sm->state = sn;
20}
21
22void state_machine_handle(struct state_machine *sm, void *data)
23{
24    switch(sm->state){
25        case s1:
26            handle_s1(sm,data);
27            break;
28
29        case s2:
30            handle_s2(sm,data);
31            break;
32
33        case sn:
34            handle_sn(sm,data);
35            break;
36    }
37}

sm->state初始化为s1。

改进实现

为了免去丑陋的switch case分支结构，在state_machine内用成员函数指针handler替代了state，改进后的框架如下。

1struct state_machine;
2typedef void (*state_handler)(struct state_machine*，void*);
3
4struct state_machine {
5    state_handler handler;
6
7};
8
9void handle_s1(struct state_machine *sm, void *data)
10{
11    //do something about state 1
12    if(is_satisfy_s2(data))
13        sm->handler = handle_s2;
14}
15
16void handle_s2(struct state_machine *sm, void *data)
17{
18    //do something about state 2
19    if(is_satisfy_s3(data))
20        sm->handler = handle_s3;
21}
22
23void handle_sn_1(struct state_machine *sm, void *data)
24{
25    //do something about state n-1
26    if(is_satisfy_sn(data))
27        sm->handler = handle_sn;
28}
29
30void state_machine_handle(struct state_machine *sm, void *data)
31{
32    sm->handler(sm, data);
33}

sm->handler初始化为handle_s1，该方法在性能上应略优于常规方法，而且逻辑更清晰自然，非常适合于网络流的处理，在nginx中分析http和email协议时，得到了广泛应用。

春秋十二月 2016-05-05 09:46 发表评论

重载运算符之应用: 支持C式结构的一些运算

春秋十二月 — Mon, 28 Oct 2013 15:37:00 GMT

摘要: 本文以系统的struct timeval为例，使其支持+、-、+=、-=4种算术运算和<，<=，>，>=，==、!= 6种关系运算，这样一来就免去了显式调用函数的麻烦，使代码简洁优雅，实现如下 Code highlighting produced by Actipro CodeHighlighter (freeware)htt... 阅读全文

春秋十二月 2013-10-28 23:37 发表评论

基于策略模式的定制new和delete

春秋十二月 — Thu, 27 Sep 2012 09:37:00 GMT

摘要: 引言在面向对象类的设计中，有时为了强化效能，特别是当构造大量小对象时，为了改善内存碎片，就需要自己实现对象的内存管理，以替换系统缺省的分配和释放行为，即全局的new和delete。按照c++标准，在定制类专属的new和delete时，为了减免客户代码使用时的麻烦和问题，需要考虑同时定制简单(normal new)、定位(placement new)和无异常(... 阅读全文

春秋十二月 2012-09-27 17:37 发表评论

一种简单的跨平台信号量

春秋十二月 — Fri, 20 Jul 2012 02:52:00 GMT

摘要: 信号量是一种用于并发环境同步手段的原语，分为无名信号量和有名信号量两种，前者只能用于线程间同步，而后者还可用于进程间同步。它包括创建、等待、挂出、取值和销毁5种基本操作。与互斥锁不同的是： ● 信号量拥有一个计数值，表示可用的资源数量，仅当该值为0或1时，则相当于互斥锁。 &... 阅读全文

春秋十二月 2012-07-20 10:52 发表评论

一种简单的跨平台互斥锁

春秋十二月 — Fri, 22 Jun 2012 16:08:00 GMT

摘要: 互斥锁，用来保证任一时刻只有单个线程或进程拥有对共享资源的互斥访问权，在这里将posix thread中的互斥体、win32中的互斥体和临界区，统称为互斥锁，其特点如下： ● 范围：线程锁和进程锁，前者仅用于同一进程内多线程间，而后者用于进程间，显然，它也能用于同一进程内多线程间，但效率较低。posix的互斥体既可以是线程锁，... 阅读全文

春秋十二月 2012-06-23 00:08 发表评论

一种简单的跨平台用户态自旋锁

春秋十二月 — Wed, 13 Jun 2012 13:02:00 GMT

自旋锁作为一种并发同步的手段，特别适用于竞争少和锁时间短的情况，在驱动及内核代码中经常被用到，本文讲述一种适合用户态程序的自旋锁，支持Windows和Linux（GCC>=4.1.2）平台，并提供了C语言的接口和实现。

接口
spin_trylock如果获取成功返回1，否则返回0；spin_is_lock如果已加锁，返回1，否则返回0。

1typedef struct
2{
3 volatile long flag_;
4 volatile long* spin_;
5}spin_lock_t;
6
7void spin_init(spin_lock_t* lock,long* flag);
8
9void spin_lock(spin_lock_t* lock);
10
11int spin_trylock(spin_lock_t* lock);
12
13void spin_unlock(spin_lock_t* lock);
14
15int spin_is_lock(spin_lock_t* lock);

实现

1#ifdef _MSC_VER
2#include <windows.h>
3#elif defined(__GNUC__)
4#if __GNUC__<4 || (__GNUC__==4 && __GNUC_MINOR__<1)
5#error GCC version must be greater or equal than 4.1.2
6#endif
7#include <sched.h>
8#else
9#error Currently only windows and linux os are supported
10#endif
11
12void spin_init(spin_lock_t* lock,long* flag)
13{
14#ifdef _MSC_VER
15    InterlockedExchange((volatile long*)&lock->flag_,0);
16    InterlockedExchange((volatile long*)&lock->spin_,flag?(long)flag:(long)&lock->flag_);
17#elif defined(__GNUC__)
18    __sync_and_and_fetch((long*)&lock->flag_,0);
19    __sync_lock_test_and_set((long*)&lock->spin_,flag?(long)flag:(long)&lock->flag_);
20#endif
21}
22
23void spin_lock(spin_lock_t* lock)
24{
25#ifdef _MSC_VER
26    for (;0!=InterlockedExchange((volatile long*)lock->spin_,1);)
27    {
28        Sleep(1);
29    }
30#elif defined(__GNUC__)
31    for (;0!=__sync_fetch_and_or(lock->spin_,1);)
32    {
33        sched_yield();
34    }
35#endif
36}
37
38int spin_trylock(spin_lock_t* lock)
39{
40#ifdef _MSC_VER
41    return !InterlockedExchange((volatile long*)lock->spin_,1);
42#elif defined(__GNUC__)
43    return !__sync_fetch_and_or(lock->spin_,1);
44#endif
45}
46
47void spin_unlock(spin_lock_t* lock)
48{
49#ifdef _MSC_VER
50    InterlockedExchange((volatile long*)lock->spin_,0);
51#elif defined(__GNUC__)
52    __sync_and_and_fetch(lock->spin_,0);
53#endif
54}
55
56int spin_is_lock(spin_lock_t* lock)
57{
58#ifdef _MSC_VER
59    return InterlockedExchangeAdd((volatile long*)lock->spin_,0);
60#elif defined(__GNUC__)
61    return __sync_add_and_fetch(lock->spin_,0);
62#endif
63}

春秋十二月 2012-06-13 21:02 发表评论

GCC原子操作类模板

春秋十二月 — Thu, 07 Jun 2012 16:19:00 GMT

摘要: 主类模板 gcc从4.1.2版本开始提供了__sync_*系列的内置API，用于加减和逻辑运算，可以对1，2，4，8字节长度的数值或指针类型进行原子操作，为方便使用，笔者对这些API作了简单的封装。 Code highlighting produced by Actipro CodeHighlighter (freeware) http://... 阅读全文

春秋十二月 2012-06-08 00:19 发表评论

模板元编程（3）：类型选择

春秋十二月 — Wed, 06 Jun 2012 05:49:00 GMT

摘要: 类型选择是一种编译时的类型计算技术，也就是根据条件判断来匹配对应的类型，功能形如运行时的if else和switch case控制结构。在这里仿真运行时的条件语句，实现了类型选择，包括if单分支、if多分支和switch case三种结构，关于其原理及细节就不多讲了，直接看如下代码（1）if单分支 Code ... 阅读全文

春秋十二月 2012-06-06 13:49 发表评论

模板元编程（2）：计算最值

春秋十二月 — Mon, 28 May 2012 17:03:00 GMT

本文就Loki编译期技术中的类型列表Typelist作了一些扩展，增加了以下几个方法：
• 获取最大和最小长度，即求取Typelist中长度最大和最小的值
• 获取最大和最小类型，即求取Typelist中长度最大和最小的类型

实现
   位于Loki::TL命名空间，利用递归计算最值结果，使用宏生成主类模板和特化类模板，其中后缀为DEFN(N为正整数)形式的宏中N表示特化类模板所带的模板参数数量，使用DEF1宏定义对应的特化类模板的原因在于：当Typelist中存在非NullType类型时，保证结果的正确性。当N为2时参数取值：name为Max则b为true；name为Min则b为false。
   主类模板
   用于定义MaxSize、MinSize和MaxType、MinType主类模板，使用宏LOKI_TYPELIST_METHOD_DEF生成。

1    #define LOKI_TYPELIST_METHOD_DEF(name)\
2    template <class TList>\
3    struct name;\
4
5    LOKI_TYPELIST_METHOD_DEF(MaxSize)
6    LOKI_TYPELIST_METHOD_DEF(MinSize)
7    LOKI_TYPELIST_METHOD_DEF(MaxType)
8    LOKI_TYPELIST_METHOD_DEF(MinType)

最大(小)长度
对应类主模板分别为MaxSize和MinSize，每种有3个特化模板，使用宏LOKI_TYPELIST_SIZE_SPEC_DEFN生成（N为0、1、2）。

1    #define LOKI_TYPELIST_SIZE_SPEC_DEF0(name)\
2    template<>\
3    struct name##Size<NullType>\
4    {\
5        enum { value = 0 };\
6    };\
7
8    #define LOKI_TYPELIST_SIZE_SPEC_DEF1(name)\
9    template<class T>\
10    struct name##Size<Typelist<T,NullType> >\
11    {\
12        enum { value = sizeof(T) };\
13    };\
14
15    #define LOKI_TYPELIST_SIZE_SPEC_DEF2(name,b)\
16    template<class T,class U>\
17    struct name##Size<Typelist<T,U> >\
18    {\
19        enum { tmp = name##Size<U>::value };\
20        enum { value = (b ? sizeof(T) > tmp : sizeof(T) < tmp) ? sizeof(T) : tmp };\
21    };\
22
23    LOKI_TYPELIST_SIZE_SPEC_DEF0(Max)
24    LOKI_TYPELIST_SIZE_SPEC_DEF0(Min)
25    LOKI_TYPELIST_SIZE_SPEC_DEF1(Max)
26    LOKI_TYPELIST_SIZE_SPEC_DEF1(Min)
27    LOKI_TYPELIST_SIZE_SPEC_DEF2(Max,true)
28    LOKI_TYPELIST_SIZE_SPEC_DEF2(Min,false)
29
30    #undef LOKI_TYPELIST_SIZE_SPEC_DEF0
31    #undef LOKI_TYPELIST_SIZE_SPEC_DEF1
32    #undef LOKI_TYPELIST_SIZE_SPEC_DEF2

最大(小)类型
对应类主模板分别为MaxType和MinType，每种有3个特化模板，使用宏LOKI_TYPELIST_TYPE_SPEC_DEFN生成（N为0、1、2）。

1    #define LOKI_TYPELIST_TYPE_SPEC_DEF0(name)\
2    template<>\
3    struct name##Type<NullType>\
4    {\
5        typedef NullType type;\
6    };\
7
8    #define LOKI_TYPELIST_TYPE_SPEC_DEF1(name)\
9    template<class T>\
10    struct name##Type<Typelist<T,NullType> >\
11    {\
12        typedef T type;\
13    };\
14
15    #define LOKI_TYPELIST_TYPE_SPEC_DEF2(name,b)\
16    template<class T,class U>\
17    struct name##Type<Typelist<T,U> >\
18    {\
19        typedef typename name##Type<U>::type R;\
20        typedef typename Select< b ? (sizeof(T)>sizeof(R)) : (sizeof(T)<sizeof(R)),T,R>::Result type;\
21    };\
22
23    LOKI_TYPELIST_TYPE_SPEC_DEF0(Max)
24    LOKI_TYPELIST_TYPE_SPEC_DEF0(Min)
25    LOKI_TYPELIST_TYPE_SPEC_DEF1(Max)
26    LOKI_TYPELIST_TYPE_SPEC_DEF1(Min)
27    LOKI_TYPELIST_TYPE_SPEC_DEF2(Max,true)
28    LOKI_TYPELIST_TYPE_SPEC_DEF2(Min,false)
29
30    #undef LOKI_TYPELIST_TYPE_SPEC_DEF0
31    #undef LOKI_TYPELIST_TYPE_SPEC_DEF1
32    #undef LOKI_TYPELIST_TYPE_SPEC_DEF2

这里用到了Loki中的Select组件来选择类型。

示例
使用LOKI中的LOKI_STATIC_CHECK宏来做编译期诊断结果正确性。

1#define LOKI_TL4 LOKI_TYPELIST_4(double,int,short,char)
2
3int main(int argc,char *argv[])
4{
5    static const int max_val = Loki::TL::MaxSize<LOKI_TL4 >::value;
6    LOKI_STATIC_CHECK(max_val==sizeof(double),max_val_should_be_sizeof_double)
7
8    static const int min_val = Loki::TL::MinSize<LOKI_TL4 >::value;
9    LOKI_STATIC_CHECK(min_val==sizeof(char),min_val_should_be_sizeof_char)
10
11    typedef Loki::TL::MaxType<LOKI_TL4 >::type max_type;
12    LOKI_STATIC_CHECK((Loki::IsSameType<max_type,double>::value),max_type_should_be_double)
13
14    typedef Loki::TL::MinType<LOKI_TL4 >::type min_type;
15    LOKI_STATIC_CHECK((Loki::IsSameType<min_type,char>::value),min_type_should_be_char)
16
17    return 0;
18}

春秋十二月 2012-05-29 01:03 发表评论

模板元编程（1）：选择API

春秋十二月 — Sat, 24 Dec 2011 11:08:00 GMT

摘要: C与C++ API的比较在c语言中，API体现为c函数，如操作系统提供的一系列API，在c++中，API体现为自由函数，这里的自由函数是指除普通成员函数、静态成员函数、友元函数外的能在某命名空间作用域或全局空间内直接访问的函数，而这更多地体现为函数模板，如stl提供的一系列算法swap、count和sort等。相对于c API，c++ API具有类型安全和封... 阅读全文

春秋十二月 2011-12-24 19:08 发表评论

真彩色静态框CColorStatic类的设计实现

春秋十二月 — Sat, 17 Dec 2011 16:54:00 GMT

摘要: 关于cstatic控件的自绘，网上也有很多的代码及文章，更有其界面画得很漂亮的、多种多样的功能。近来我自行封装实现了一个真彩色静态框类，目标初衷是从颜色、字体、光标入手，改变原始标准cstatic的色彩风格，使界面初步美化，具有好看的效果。同时作为一个基础简单的类来维护，为后续的功能增强及美化提供参考扩展，这个CColorStatic类的特点及功能如下：（1）文... 阅读全文

春秋十二月 2011-12-18 00:54 发表评论

使用子类化截获窗口消息

春秋十二月 — Sun, 11 Dec 2011 03:07:00 GMT

摘要: 在《多标签视图类CTabView的设计实现》一文中，CTabView从CBasicSubClassWnd私有继承，重写其虚函数SubWindowProc，捕获WM_DRAWITEM和TTN_GETDISPINFO消息，从而实现了DrawItem和UpdateTooltipText虚函数回调机制，支持派生类的自定义处理，而CBasicSubClassWnd就是一个... 阅读全文

春秋十二月 2011-12-11 11:07 发表评论

多标签视图类CTabView的设计实现

春秋十二月 — Sat, 10 Dec 2011 16:47:00 GMT

摘要: 在MFC9（在vc2008和vc2010中，已经有了CTabView的现成类）以前的版本中，有CListView,CTreeView,CEditView,CRichEditView等控件视图类，但就是没有类似的CTabView类，因工作需要，最近在做一个简单的多标签IE浏览器，开发环境是vs2005，基本框架是sdi + chtmlview + ctabview... 阅读全文

春秋十二月 2011-12-11 00:47 发表评论

观察者模式之应用: 系统托盘图标类的设计

春秋十二月 — Sat, 03 Dec 2011 19:15:00 GMT

摘要: 关于系统托盘图标类，网上也有很多的代码，但都不太简洁灵活易用，为了这一目的，本人自行封装了一个API版本的实现类，这个类的设计思想来源于观察者模式，从而较好地解耦了托盘通知消息的发送、接收、处理这三者间的关系，使这三者可以是同一个对象，也可以是不同的对象，具体的情况可根据业务逻辑灵活选择控制，主要包括以下几方面的特点：1）对于托盘通知消息的接收处理，提供了一个默... 阅读全文

春秋十二月 2011-12-04 03:15 发表评论

default constructor和copy constructor小结

春秋十二月 — Wed, 31 Aug 2011 03:40:00 GMT

   一、default constructor---默认构造函数，亦即无参构造函数。从对象构造语义上讲，可分为以下2种：1）trivial 平凡的，可以理解为浅构造 2）notrivial 非平凡的，可以理解为深构造。当一个class没有显式地(explicitly)声明或定义任何constructor的时候，一个default constructor就会被编译器隐式地（implicitly)声明或定义出来。那么这个implicitly default constructor到底是trivial还是notrivial的呢？对于一个class，当存在以下4种情况时，其implicitly default constructor就是notrivial的。
   （1）class内含一个或多个成员对象(member object)，且这些member object中至少一个存在default constructor（无论是显式的default constructor还是隐式的notrival default constructor）
   （2）class派生自一个继承串链，其中至少有一个base class存在default constructor（再次强调，无论是显式的default constructor还是隐式的notrival default constructor）
   （3）class声明一个或多个虚函数(virtual function)
   （4）class派生自一个继承串链，其中至少有一个虚基类(virtual base class)，而不管这些virtual base class是否存在default constructor
   显而易见，这4种情况是正交的，当不存在以上4种情况时，其implicitly default constructor就是trivial的。只有notrivial的default constructor才会被编译器真正生成，而trivial的不会生成。

   二、copy constructor---拷贝构造函数，亦即带有当且仅有一个参数，类型为同类对象的构造函数。从对象拷贝语义上讲，可分为以下2种：1）bitwise copy 位拷贝，可以理解为浅拷贝 2）no bitwise copy 非位拷凡，可以理解为深拷贝。当一个class没有显式地声明或定义copy constructor时，一个copy constructor就会被编译器隐式地声明或定义出来。那么这个implicitly copy constructor到底是bitwise copy还是no bitwise copy的呢？对于一个class，当存在以下4种情况时，其implicitly copy constructor就是no bitwise copy的。
   （1）class内含一个或多个成员对象，且这些member object中至少一个存在copy constructor（无论是显式的copy constructor还是隐式的no bitwise copy constructor）
   （2）class派生自一个继承串链，其中至少有一个base class存在copy constructor（再次强调，无论是显式的copy constructor还是隐式的no bitwise copy constructor）
   （3）class声明一个或多个虚函数
   （4）class派生自一个继承串链，其中至少有一个虚基类，而不管这些virtual base class是否存在copy constructor
   显而易见，这4种情况是正交的，当不存在以上4种情况时，其implicitly copy constructor就是bitwise copy的。只有no bitwise copy的copy constructor才会被编译器真正生成，而bitwise copy的不会生成。

   三、对于defualt constructor，当一个class内显式地存在constructor（包括default constructor）时，编译器不会再生成它，但如果这个class满足以上4种情况至少一种时，编译器就需要负责执行相关的初始化：对于(1)要调用成员对象的default constructor；对于(2)要调用基类的default constructor；对于(3)要设定虚函数表的指针；对于(4)要设定虚基类的指针和偏移量。而这些初始化在用户代码执行前。

   四、对于copy constructor，当一个class内显式地存在copy constructor时，编译器不会再生成它，但如果这个class满足以上情况(3)或(和)(4)时，编译器就需要负责执行相关的拷贝：对于(3)要决定怎么设定虚函数表指针。对于(4)要决定怎么设定虚基类的指针和偏移量。同理类推，如果这个class满足情况(1)或(和)(2)，而且其成员对象或基类子对象又满足情况(3)或(和)(4)时，编译器也需要负责执行相关的拷贝了。而这些拷贝在用户代码执行前。

春秋十二月 2011-08-31 11:40 发表评论

多窗口的组合与分离（2）：实现

春秋十二月 — Sat, 27 Aug 2011 07:12:00 GMT

摘要: Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/--> 1/***************************************************************************************&... 阅读全文

春秋十二月 2011-08-27 15:12 发表评论

多窗口的组合与分离（1）：接口

春秋十二月 — Mon, 04 Jul 2011 03:14:00 GMT

   著名的千千静听音乐播放器，其界面简洁优雅、美观大方，特别是它那种几个窗口像磁石般相互吸引，当拖动主窗口时，粘在一起的其它窗口会跟随着一起移动，当拖动其它窗口时，又能脱离不粘在一起，这种窗口效果让用户操作方便，省心省力。为描述方便，本文称这种效果为多窗口的组合分离，它的主要特点是仅用鼠标任意移动窗口，就可组合或分离，当组合在一起时，移动某窗口（如主窗口，暂称为老板窗口）能整体移动，移动其口窗口（非老板窗口，暂称为工人窗口）又能将自己脱离出来。近来由于工作需要实现了类似于此的窗口效果，经过几天的测试，终于稳定。在开发过程中，考虑了以下几个问题：
     (1) 组合分离的条件如何决定判断。
     (2)  当窗口大小改变时，包括最小化，最大化，缩放窗口等，如何保证不影响组合分离，能正常整体移动。
     (3) 窗口个数是可变的，当新建或销毁窗口时，如何保证不影响组合分离，能正常整体移动(千千静听窗口个数是有限的，而且可能只是隐藏窗口）。
     (4) 采用什么数据结构较好，如何维护任意两个窗口间的距离关系（相交或相切视为组合，相离视为分离）。
     (5) 当拖动老板窗口时，如何拖动与其组合的所有窗口，关键是如何得到所有与其组合的窗口列表。
     (6) 如何针对这种效果设计一个通用的组件类，只需调用几个方法便可搞定。

   针对以上问题，主要思路是视屏幕上任意多个窗口为顶点，以其窗口矩形中心点来看待这个窗口，如果任意两个窗口间关系为组合，则视这两个顶点间是相通的，即两个顶点存在边。如果为分离，则视两顶点间是不通的，即两顶点不存边。因此可以用无向图来存储窗口和关系，为简单起见，我用的是邻接矩阵，问题(4)得以解决。既然用邻接矩阵来存储，那么如何得到所有与老板窗口相关的组合窗口呢？由于实际多个窗口在移动过程中，会改变其组合分离关系，这就会得到多个无向图的连通分量，而我们需要的是包含老板窗口的那一个连通分量，因此可以用DFS深度搜索遍历这个无向图连通分量，起始顶点是老板窗口，遍历完后就会得所有与其组合的窗口列表，问题(5)得以解决。现在讨论问题(1)，这里有个细节问题就是组合分离的条件判断有两种情况，一是当移动窗口时的条件，称为条件1，因为实际向一个窗口A移入另一个窗口B时，要达到还没有接近窗口A时便一下子靠近A就像被A吸引的效果，当移出B时还没完全移到A窗口外面时便一下子远离就像被A排斥的效果。二是当大小改变时的条件，称为条件2，这个不同于条件1，因为它不需要那种吸引排斥的效果，也没必要，这个条件2就是简单的判断A和B矩形是否相交，API函数IntersectRect即可完成这一判断。条件1的判断如下图所示：

   在B向A移入过程中,当B的中心点在矩形left,top,right,bottom范围内,可认为是发生组合,实现吸引效果；当在center矩形内，认为是已经组合了；同理，B向A移出过程中，当B的中心点在矩形left,top,right,bottom范围内,可认为是发生分离，实现排斥效果。当都不在left,top,right,bottom,center矩形范围时，认为是已经分离了。至此，问题(1)得到解决。当窗口大小改变时，需要更新邻接矩阵反映窗口间关系的变化，而后更新组合窗口列表，组合窗口列表的计算依赖于邻接矩阵，运用DFS算法来更新，这在WM_SIZE消息事件处理内完成，问题(2)得到解决。当新建窗口时，需要向无向图中增加(窗口)顶点，扩充邻接矩阵以备存储与其它窗口的关系；当销毁窗口时，需要从无向图中删除对应的顶点，而后从邻接矩阵中删除对应的关系，问题(3)得到解决。
   上述问题(1)--(5)都已分析并得到解决，总的来说，就是以数据结构中无向图的观点和算法来建模解决这些问题的，特别是运用到了DFS搜索算法来重建已组合的所有窗口列表，只有这样，在移动老板窗口过程中，才能保证其它窗口跟随着一起移动。接下来就是最后一个问题，也就是怎么封装设计组件类，以达到方便应用的目的，综上所述，设计接口方法与以下窗口4种消息相关：
   1) 创建窗口发生的消息,如WM_CREATE,WM_INITDIALOG等。
2) 关闭或销毁窗口发生的消息，如WM_CLOSE，WM_DESTROY等。
3) 窗口大小改变后消息，WM_SIZE。
4) 窗口移动中消息，WM_MOVING。

   另外提供一个设置获取老板窗口的方法，在应用程序中，只需在窗口4种消息处理内调用以上对应4个方法即可实现多窗口组合分离的效果，注意该类没有考虑多线程，因此是非安全的，适用于多窗口属于同一线程内的情况。类声明如下

1class CWndMagnet
2{
3public:
4    CWndMagnet();
5  virtual ~CWndMagnet();
6
7public:
8    void SetLeadWindow(HWND hWnd) { m_hLead = hWnd; }
9    HWND GetLeadWindow() const { return m_hLead; }
10
11    void AddMagnetWnd(HWND hWnd);
12    void RemoveMagnetWnd(HWND hWnd);
13    void OnLButtonDown(HWND hWnd);
14    void OnNcLButtonDown(HWND hWnd);
15    void OnMoving(HWND hWnd, LPRECT lpRect);
16    void OnSize(HWND hWnd, UINT uType);
17
18protected:
19    void MoveLeadWndSet(HWND hWnd, LPCRECT lpRect);
20    void UpdateLeadWndSet(HWND hWnd, LPCRECT lpRect = 0);
21    void DeleteMagWnd(HWND hWnd);
22    void Add2DMatrix();
23    void Delete2DMatrix(HWND hWnd);
24    void Update2DMatrix(HWND hWnd, LPRECT lpRect = 0);
25
26private:
27    int GetFirstNeighbor(int v);
28    int GetNextNeighbor(int v, int w);
29    void DFS(int v, std::vector<bool>& vecVisited, std::vector<int>& vecNeighbor);
30
31private:
32    static const int      s_c_iThreshold = 10; ///< 偏移阀值
33    HWND                  m_hLead;        ///< 老板窗口
34    std::map      m_map_leadWnd;  ///< 粘合窗口列表
35    std::map        m_map_magWnd;   ///< 需要组合分离的窗口列表
36    std::vector > m_vec_2DMatrix; ///< 表示任意两个窗口间相交或相切的邻接矩阵
37
38};

春秋十二月 2011-07-04 11:14 发表评论

模板类的数组特化

春秋十二月 — Thu, 23 Jun 2011 04:01:00 GMT

摘要: 一般地，泛型容器的设计实现大多只是存储了类型的单个对象，而没有存储类型的多个对象，如果有这样特定的需求，容器内的元素要求都是某个类型的多个对象，那么这时就可以考虑用模板类的数组特化来实现了，作为例程，下面C++代码描述了主模板实现 Code highlighting produced by Actipro CodeHighlighter (freewa... 阅读全文

春秋十二月 2011-06-23 12:01 发表评论

ATL和WTL中的消息反射

春秋十二月 — Mon, 14 Jun 2010 09:50:00 GMT

   WTL是窗口模板库(Windows Library Template)的简称，是一套轻量级C++ GUI库，因为它使用了C++模板封装了窗口界面操作API和消息映射处理，它扩展了ATL中的UI窗口部分，并支持如下更多的功能特性：
    (1)   对话框和通用控件：包括对话框数据交换(DDX)，子类化，控件消息通知与反射等
    (2)   工具栏和状态栏：包括工具条UI状态更新，多窗格状态条及UI状态更新等
    (3)   分隔窗口：包括窗格容器，嵌套分隔，特殊绘制等
    (4)   属性页和向导：包括属性表，普通属性页，向导属性页等
    (5)   GDI类等：包括GDI封装类，通用对话框等
    (6)   使用ActiveX控件：包括使用控件类，调用控件的方法，控件事件映射处理等
    (7)   高级对话框UI类：包括自绘和外观定制类，新控件类，控件UI状态更新，对话框数据验证DDV等
    (8)   支持拖放操作：包括拖放接口实现类，最近使用文件列表等
综上所述，使用WTL几乎可以实现MFC所能实现的功能与界面，而且生成的执行文件体积更小，不需要动态链接库就可直接快速地执行。

   根据WIN32窗口原理，当事件发生的时候，一般由父窗口接收其子窗口或控件的通知或命令消息，在这里父窗口是消息接收者，子窗口或控件是消息发送者，那么谁是消息处理者呢？实际上由谁来处理消息只是代码上的逻辑，既可以在父窗口的窗口过程回调内处理，也可以在子窗口或控件的窗口过程回调内处理，在哪处理更方便合理就在哪处理，如果是在子窗口或控件窗口过程回调内处理，那么就需要作额外的处理了，也就是在父窗口中将消息反射给发送者，进而再由发送者处理。下面以父窗口为打开文件对话框，双击它的列表视图控件为例，给出运用上面(1)中的控件消息通知与反射来处理NM_DBLCLK消息的两种实现方式。

   继承方式：由控件处理消息
   从CWindowImpl模板基类派生一个子窗口或控件子类即listview子类，添加消息映射项和消息处理函数，消息映射项用REFLECTED_NOTIFY_XXX或REFLECTED_COMMAND_XXX系列反射宏实现，具体使用哪个宏，决定于是否通知或命令消息，及消息对应的ID和通知码。

1class CFileListViewCtrl : public CWindowImpl<CFileListViewCtrl, CListViewCtrl>
2{
3 protected:
4      BEGIN_MSG_MAP(CFileListViewCtrl)
5          REFLECTED_NOTIFY_CODE_HANDLER_EX(NM_DBLCLK,OnListViewDblclk)   //反射通知消息处理宏
6          CHAIN_MSG_MAP(CListViewCtrl)
7     END_MSG_MAP()
8    LRESULT OnListViewDblclk(NMHDR* pNMHDR);   //消息响应处理函数
9};

在父窗口类消息映射链中最后添加反射通知宏REFLECT_NOTIFICATIONS()项。

　成员方式：由父窗口处理消息
直接使用ATL中的包含窗口模板类CContainedWindowT，参数为子控件的类名即listviewctrl，实例化为父窗口类的一个成员变量，在父窗口类消息映射链中添加ALT_MSG_MAP宏来实现消息分派，其参数为分派ID，这个ID为成员变量初始化时指定的常量；添加反射通知宏REFLECT_NOTIFICATIONS()，注意ALT_MSG_MAP宏必须在反射通知宏REFLECT_NOTIFICATIONS之后。

1class COpenFileDlg : public CDialogImpl<COpenFileDlg> ,　 public CWinDataExchange<COpenFileDlg>
2{
3    public:
4        COpenFileDlg();
5       ~COpenFileDlg();
6  enum  { IDD = IDD_OPEN_FILE_DLG };
7
8  protected:
9     BEGIN_MSG_MAP(COpenFileDlg)
10          MESSAGE_HANDLER(WM_INITDIALOG,OnInitDialog)
11          REFLECT_NOTIFICATIONS()           //  消息反射通知宏
12          ALT_MSG_MAP(1)                             //  消息分派宏
13          REFLECTED_NOTIFY_CODE_HANDLER_EX(NM_DBLCLK,OnListViewDblclk)     // 反射通知消息处理宏
14     END_MSG_MAP()
15
16     BEGIN_DDX_MAP(COpenFileDlg)
17           DDX_CONTROL(IDC_LIST_FILE,m_list_File)
18     END_DDX_MAP()
19
20     LRESULT OnInitDialog(UINT uMsg,WPARAM wParam,LPARAM lParam,BOOL& bHandle);
21     LRESULT OnListViewDblclk(NMHDR* pNMHDR);            //消息响应处理函数
22  private:
23    CContainedWindowT<CListViewCtrl>   m_list_File;    //  实例化包含窗口模板类作为成员变量
24 };

在父窗口内需要初始化m_list_File以指定分派ID号。

1COpenFileDlg:: COpenFileDlg():
2m_list_File(this,1) // 指定消息分派ID为1
3{
4}

春秋十二月 2010-06-14 17:50 发表评论

深入MFC中WM_COMMAND的传递

春秋十二月 — Sat, 19 Dec 2009 13:29:00 GMT

MFC将windows消息系统进行了高度的抽象和封装，其根本原理是运用C++的高级特性并结合一定的设计模式（如工厂模式，模板方法等）来实现的。一般的windows消息（WM_XXX），则一定是由派生类流向基类，没有旁流的可能。如果是命令消息（WM_COMMAND），那就有比较奇特的路线了。下面就针对多文档/单文档（Document-View）、对话框两种应用程序比较讨论WM_COMMAND消息的传递处理过程。讨论前首先得明确命令消息的来源，命令消息一般是用户选择某个菜单项，或一个加速键被翻译，或一个子控件发送一个通知消息给它的父窗口时产生的。对一个菜单而言，消息接收者是Frame窗口或拥有它的对话框；对一个工具栏而言，消息接收者是它的父窗口。两种应用程序命令消息处理流程如下图所示。

从上图可知，文档视图型的处理路线是先向下再向上，而对话框型的路线是一直向上，消息接收者只有一个，而处理者次序有多个，每个处理者内部首先都是调用根基类CCmdTarget的OnCmdMsg虚函数，在这个函数内逐级向基类遍历消息映射表，根据命令ID和通知码找到对应的消息映射结构体AFX_MSGMAP_ENTRY，如果找到再处理这个命令消息，否则返回FALSE，退回到this对象所在的OnCmdMsg函数进行下一步处理。如果到最后一层都没有找到对应命令的消息映射，则返回到系统的默认处理DefWindowProc。再综合考虑下，如果一个对话框接收到了一个命令消息例如是点击它的子控件工具栏某个按钮发出的，而这个对话框类没有添加相应的ON_COMMAND映射，就会进入到它的父窗口类OnCmdMsg函数进行处理，如果这个父窗口正好是Frame窗口，那么命令消息的处理流程就由上图右边转到左边了。而最终命令消息能否得处理，就看上图5种对象（Frame、View、Document、Dialog、App、Thread）是否添加了对应的ON_COMMAND映射。

到此为止，我们已经明确了WM_COMMAND消息的处理流程，但是发现最终处理却是由收到消息的窗口传递的，不是消息通知者自己处理的，有的时候为了提高代码的封装性，可能需要自己处理这些命令比较方便，比如有一个工具栏CPlayToolBar子类从CToolBar继承，有播放、暂停、停止3个按钮，它的父窗口是CPlayDialog对话框。按照常规，这3个按钮命令事件的处理一般是在CPlayDialog类中3个ON_COMMAND映射宏和处理函数的，但如果在CPlayToolBar类中添加3个ON_COMMAND映射宏和处理函数，是得不到处理的，其原因在于对话框型的路线是一直向上，再者MFC中没有对应的命令反射ON_COMMAND_REFLECT这个宏。为了能使CPlayToolBar类自己处理这3个按钮命令事件，就需要从CPlayDialog类中转移路线，使之流向其子窗口工具栏，这样CPlayToolbar 类就得到了自己处理的机会。具体操作是重载CPlayToolBar和CPlayDialog的OnCommand虚函数, CPlayDialog代码如下所示：

1  BOOL   CPlayDialog::OnCommand(WPARAM wParam, LPARAM lParam)
2  {
3         if (lParam==(LPARAM)m_playtoolbar.m_hWnd)
4        {
5              m_playtoolbar.OnCommand(wParam,lParam);   //m_playtoolbar为CPlayToolBar对象，注意使OnCommand成为公有成员
6        }
7       else
8       {
9            return   CDialog::OnCommand(wParam, lParam);
10       }
11   }

CPlayToolBar类代码如下所示

1    BEGIN_MESSAGE_MAP(CPlayToolBar, CToolBar)
2         ON_COMMAND(ID_PLAY,  Play)
3         ON_COMMAND(ID_PAUSE,  Pause)
4         ON_COMMAND(ID_STOP,  Stop)
5    END_MESSAGE_MAP()
6
7    void   CPlayToolBar::Play()
8    {
9    }
10   void   CPlayToolBar::Pause()
11   {
12   }
13   void   CPlayToolBar::Stop()
14   {
15   }

现在，3个按钮命令事件能在CPlayToolBar类中独立处理了，这样一来就提高了代码的封装性，简化了父窗口CPlayDialog类的处理。

春秋十二月 2009-12-19 21:29 发表评论

basic_string内存泄露问题之分析解决

春秋十二月 — Thu, 06 Aug 2009 17:31:00 GMT

最近在工作中,写一计算杆塔绝缘子中心点的GPS坐标程序时，定义了一结构，里面用到了string类型来存储杆塔所属线路号、杆塔号，杆塔模型名称。代码如下:

1/*
2  @brief 杆塔信息结构
3*/
4typedef struct   _TOWER_INFO
5{
6       string    strLineNo;           ///< 线路号
7       string    strTowerNo;         ///< 杆塔号
8       string    strTowerType;     ///< 杆塔类型
9       double dDangDistance;    ///< 档距
10      double dHCHeight;           ///< 呼称高
11      double dLongitude;          ///< 经度
12      double dLatitude;              ///< 纬度
13      double dAltitude;              ///< 海拔高度
14      double dLineCorners;      ///< 线路转角
15      long      lCornerDirection;  ///< 左转还是右转: 0不转, 1左转, 2右转
16      vector<INSULATOR_INFO::CENTER_POINT_INFO>  vecInsulatorCenterPointInfo; ///< 杆塔所有绝缘子中心点信息
17       _TOWER_INFO() { memset(this, 0, sizeof(_TOWER_INFO)); }       //该行代码可能会引起string内存泄露
18
19}TOWER_INFO,*PTOWER_INFO;

在后面对该结构的string型变量有赋值操作, 代码如下

1   ......
2       TOWER_INFO cur_tower_center_info;
3   cur_tower_center_info.strLineNo = sheetLine->Cell(i, 2)->GetText(); //调度码
4   cur_tower_center_info.strTowerNo = sheetLine->Cell(i, 7)->GetText(); //杆塔号
5   cur_tower_center_info.strTowerType = sheetLine->Cell(i, 8)->GetText(); //杆塔类型
6      ......

运行程序,待程序结束后,发现有内存泄露,提示信息如下

1Detected memory leaks!
2Dumping objects ->
3{235250} normal block at 0x01774A60, 16 bytes long.
4 Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
5{235237} normal block at 0x01774CB0, 16 bytes long.
6 Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
7{235234} normal block at 0x01774A10, 16 bytes long.
8 Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
9{235184} normal block at 0x01774200, 16 bytes long.
10 Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
11{235171} normal block at 0x01774450, 16 bytes long.
12 Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
13{235168} normal block at 0x017741B0, 16 bytes long.
14 Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
15{235118} normal block at 0x017739A0, 16 bytes long.
16 Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
17{235105} normal block at 0x01773BF0, 16 bytes long.
18 Data: <                > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
19..

经过一番源代码跟踪调试后,发现原因在于TOWER_INFO结构体的构造函数内调用了memset(this, 0, sizeof(_TOWER_INFO);使得string内部指针_Bx._Ptrr值为0,_Myres为0,在这种情况下当string对象被赋值为小字符串(字节数包括结束符小于等于16的字符串)时,因新申请的内存在后来得不到释放,所以这块内存被泄露了,根据string类内存管理算法(ms vc版本)得知这块内存大小总是16个字节.但当被赋值为大字符串(字节数包括结束符大于16的字符串)时,反而没有内存泄露,这是因为新申请的内存在析构或下次赋值时总能被释放.
从该泄露问题的分析解决过程中，总结得到规律：不要轻易零初始化string, vector等stl标准容器及具有动态内存管理的类。

春秋十二月 2009-08-07 01:31 发表评论

串口通讯与超时设置

春秋十二月 — Fri, 17 Apr 2009 11:15:00 GMT

在WINDOWS NT4.0 以上操作系统中，串口通讯有2种模式：同步方式和异步方式。由CreateFile中的dwFlagsAndAttributes参数决定，若指定FILE_FLAG_OVERLAPPED标志则为异步方式，否则为同步方式。当为同步模式时,调用ReadFile或WriteFile会阻塞调用线程直到读完或写完指定量的数据才返回，这样就有可能出现无法退出程序的现象，解决方法是为读写操作设置超时，注意这种超时指的是ReadFile或WriteFile函数的返回时间，仅对同步模式有效。代码如下

1   //以下m_pComPort为本人自己封装的C++串口类CComPort的指针
2
3            // FALSE表示以同步方式打开
4           m_pComPort->Open(2, FALSE, 38400);
5
6          //设置读写超时为5秒
7               COMMTIMEOUTS  timeout = { 0 };
8           timeout.ReadTotalTimeoutConstant = 5000;
9           timeout.WriteTotalTimeoutConstant = 5000;
10          m_pCommPort->SetTimeouts(timeout);
11
12            char  szData[1024] = { 0 };
13         //读数据
14         DWORD dwRet = m_pCommPort->ReadComm(szData, 1024);
15         //写数据
16         dwRet = m_pCommPort->WriteComm(szData, 1024);
17         //关闭串口
18         m_pCommPort->Close();

当为异步模式时，由于读写操作会立即返回，因此设置超时指的是设置等待操作完成的时间，而不是ReadFile或WriteFile函数返回的时间，代码如下

1    //以下m_pComPort为本人自己封装的C++串口类CComPort的指针
2
3           // TRUE表示以异步方式打开
4            m_pComPort->Open(2, TRUE, 38400);
5
6          //设置读写等待超时为5秒
7                char  szData[1024] = { 0 };
8
9         //当第3个参数为0时，读写操作会立即返回
10           //读数据
11           DWORD dwRet = m_pCommPort->ReadComm(szData, 1024, 5000);
12          //写数据
13           dwRet = m_pCommPort->WriteComm(szData, 1024, 5000);
14          //关闭串口
15           m_pCommPort->Close();

这里的ReadComm和WriteComm的实现内部针对不同模式作了不同处理，异步模式时即调用了WaitForSingleObject等待函数来设置超时。同步模式时即调用不带重叠结构的ReadFile或WriteFile函数来接收或发送指定量的数据。另外在这介绍下串口虚拟软件vspd，这个软件能模拟在同一台计算机上进行两个串口的通讯，有利于没有实际设备情况下的串口调试。

春秋十二月 2009-04-17 19:15 发表评论

工作线程与消息循环

春秋十二月 — Wed, 15 Apr 2009 10:11:00 GMT

首先声明，这里的工作线程与UI线程是相对的，即没有任何窗口的。如果需要与主线程或其它辅助线程通讯，有几种方法如事件、消息和信号等，也可以是以上几种方法的综合运用。下面就列出以下3种通讯方法的代码框架。

只用消息通讯

1  DWORD ThreadProc(LPVOID lParam)
2  {
3      //创建线程消息队列
4      MSG msg;
5      PeekMessage(&msg, NULL, WM_USER, WM_USER, PM_NOREMOVE);
6      //通知其它线程消息队列已创建好
7      SetEvent(hEvent);
8
9      while(true)
10    {
11        GetMessage(&msg, NULL, 0, 0);
12        switch(msg.message)
13         {
14            case WM_QUIT:
15                  return 1;
16
17            //自定义消息1处理
18            case WM_USER + 100:
19                  break;
20
21            //自定义消息2处理
22            case WM_USER + 101:
23                  break;
24         }
25    }
26    return 0;
27 }

只用事件通讯

1  DWORD ThreadProc(LPVOID lParam)
2  {
3       DWORD dwIndex;
4       while (true)
5       {
6           dwIndex = WaitForMultipleObjects(cObjects, pObjects, FALSE, INFINTE);
7           if (WAIT_OBJECT + 0== dwIndex)
8            {
9               return 1;     //假设为退出事件
10         }
11         else if (WAIT_OBJECT + 1 == dwIndex)
12         {
13             //事件1受信，处理之
14         }
15
16         else if (WAIT_OBJECT + cObjects - 1 == dwIndwx)
17         {
18             //事件cObjects - 1受信, 处理之
19         }
20     }
21 }

用消息和事件通讯

1 DWORD ThreadProc(LPVOID lParam)
2 {
3    while (TRUE)
4   {
5         DWORD ret ;
6         MSG msg ;
7
8         while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
9         {
10         switch(msg.message)
11          {
12            //线程退出消息,直接返回
13             case WM_QUIT:
14                 return 1;
15
16            //自定义消息1处理
17             case WM_USER + 100:
18                 break;
19             //自定义消息2处理
20            case WM_USER + 101:
21                break;
22          }
23        }
24        ret = MsgWaitForMultipleObjects(cObjects, lphObjects, FALSE,INFINITE,QS_POSTMESSAGE);
25        if (ret == (WAIT_OBJECT_0 + cObjects))
26        {
27           //有新的消息到来,继续到上步PeekMessage处理
28           continue;
29        }
30        else
31        {
32           //是事件受信了
33          if (ret == WAIT_OBJECT_O)
34          {
35          }
36          else if (ret == WAIT_OBJECT_O + 1)
37          {
38          }
39          else if(ret == WAIT_OBJECT_O + cObjects - 1)
40          {
41          }
42       }
43     return 0;
44 }

上面用到了GetMessage和PeekMessage 函数，这两者都是从消息队列取出消息，不同的是GetMessage从消息队列删除消息，并且阻塞调用线程。PeekMessage则是查询消息队列，如果有消息就取出，没有消息也立即返回，是否从消息队列删除消息由最后一个参数决定:PM_REMOVE表示删除，PM_NOREMOVE表示不删除。可以简单地认为，GetMessage是同步的，PeekMessage是异步的。

春秋十二月 2009-04-15 18:11 发表评论

C++博客-一年十二月 谁主春秋-随笔分类-C/C++