摘要:    一般地，泛型容器的设计实现大多只是存储了类型的单个对象，而没有存储类型的多个对象，如果有这样特定的需求，容器内的元素要求都是某个类型的多个对象，那么这时就可以考虑用模板类的数组特化来实现了，作为例程，下面C++代码描述了主模板实现 Code highlighting produced by Actipro CodeHighlighter (freewa...  阅读全文    原为某软件公司试题，大意如下：对于给定的有符号32位整数，写一个函数，当该数为正数时返回1，为负数时返回-1，为零时返回零，要求不能使用任何的条件判断分支跳转语句。在这里，稍微扩展了一下，给出了对应无符号32位整数的情形。解决思路是符号位和值分开处理，对于有符号32位整数，符号位右移31位即得a，若为非负数则a=0x00000000，否则a=0xFFFFFFFF；然后将值部分各位的值（0或1）不断缩小合并到一位中去得到b，这是针对0和正数的情况处理，再将a和b位或即可。C++代码描述如下    若哪位有更好的解法，还望多多分享    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和通知码。    
   在父窗口类消息映射链中最后添加反射通知宏REFLECT_NOTIFICATIONS()项。                                           
　成员方式：由父窗口处理消息 
   直接使用ATL中的包含窗口模板类CContainedWindowT，参数为子控件的类名即listviewctrl，实例化为父窗口类的一个成员变量，在父窗口类消息映射链中添加ALT_MSG_MAP宏来实现消息分派，其参数为分派ID，这个ID为成员变量初始化时指定的常量；添加反射通知宏REFLECT_NOTIFICATIONS()，注意ALT_MSG_MAP宏必须在反射通知宏REFLECT_NOTIFICATIONS之后。  
   在父窗口内需要初始化m_list_File以指定分派ID号。                                                               

   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代码如下所示：    CPlayToolBar类代码如下所示     现在，3个按钮命令事件能在CPlayToolBar类中独立处理了，这样一来就提高了代码的封装性，简化了父窗口CPlayDialog类的处理。    最近在工作中,写一计算杆塔绝缘子中心点的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标准容器及具有动态内存管理的类。

   上次介绍了一种字符串转化为16进制显示的算法，并封装成了API，这个API可用于串口收到数据后按16进制显示字符串，这次介绍串口按16进制发送字符串的算法，使用基于字符类型参数的模板函数实现。算法原理是遍历字符串，将在区间'0'--'9','A'--'F','a'--'f'的字符转化成对应的16进制整数(范围为闭区间0-15)，如遇到连续2个可以转换的字符，则将它们存储在一个无符号字节内，如遇到不能转化的字符，则略过继续。代码如下:

 1/**//**
 2    @brief 将字符转化为对应的10进制数整数 ASCII版本 
 3    * 若字符不能转化则返回-1
 4*/
 5template<typename charT>
 6inline char ConvertHexChar(charT ch)
 7{
 8    if(ch>=(charT)'0'&&ch<=(charT)'9')
 9        return ch-(charT)'0';
10    else if(ch>=(charT)'A'&&ch<=(charT)'F')
11        return ch-(charT)'A'+10;
12    else if(ch>=(charT)'a'&&ch<=(charT)'f')
13        return ch-(charT)'a'+10;
14    else 
15        return -1;
16}
17
18typedef std::vector<unsigned char> CByteArrayEx;
19
20/**//**
21    @brief 将字符串转化成对应的16进制数形式存储
22    @param template charT 源字符类型
23    @param src 源数据串
24    @param size 要转换的长度,字符数
25    @param ByteArray 存放结果的字节数组
26
27    * 如字符串80 12 34 46 AD FF,对应的就是0x80,0x12,0x34,0x46,0xAD,0xFF
28    该函数会自动过滤不能转换的字符,可转换字符范围在0--9,a--f,A--F区间   
29*/
30template<typename charT>
31inline void StrToHex(const charT* src,size_t len,CByteArrayEx& ByteArray)
32{
33    char low = -1, high = -1;
34    for (size_t n = 0; n < len; )
35    {
36        high = ConvertHexChar(src[n++]); 
37        if (-1 == high)
38        {
39            continue;
40        }
41        if (n >= len)
42        {
43            ByteArray.push_back(high);
44            break;
45        }
46        low = ConvertHexChar(src[n++]);
47        if (-1 == low)
48        {
49            ByteArray.push_back(high);
50            continue;
51        }
52        ByteArray.push_back(high * 16 + low);  
53    }
54}
55
56/**//**
57    @brief 将字符串转化成对应的16进制数形式存储
58    @param template charT 源字符类型
59    @param src 源数据串
60    @param ByteArray 存放结果的字节数组  
61*/
62template<typename charT>
63inline void StrToHex(const charT* src,CByteArrayEx& ByteArray)
64{
65    StrToHex(src,select_variable<is_ansi_char<s_charT>::value>(strlen,wcslen)(src),ByteArray);
66}

 

   最近在项目中调试串口,,总结封装了字符串转化为16进制显示的算法,串口数据发送一般为ASCII和16进制两种,当收到数据时数据也有ASCII和16进制显示两种方式,下面给出一种转化算法,该算法基于字符类型参数化的模板实现，字符串的转化只是调用其内存版本，算法原理是对字符串内存进行操作转化,以一个字节(unsigned char类型)为单位,分别取其高4位和低4位(范围为0x0--0xF), 转化为对应的目标字符('0'--'F')显示,代码如下    在应用中需要转化时, 只需调用StrToHex函数,示例如下:      结果输出如下:    在WINDOWS NT4.0 以上操作系统中，串口通讯有2种模式：同步方式和异步方式。由CreateFile中的dwFlagsAndAttributes参数决定，若指定FILE_FLAG_OVERLAPPED标志则为异步方式，否则为同步方式。当为同步模式时,调用ReadFile或WriteFile会阻塞调用线程直到读完或写完指定量的数据才返回，这样就有可能出现无法退出程序的现象，解决方法是为读写操作设置超时，注意这种超时指的是ReadFile或WriteFile函数的返回时间，仅对同步模式有效。代码如下    当为异步模式时，由于读写操作会立即返回，因此设置超时指的是设置等待操作完成的时间，而不是ReadFile或WriteFile函数返回的时间，代码如下    这里的ReadComm和WriteComm的实现内部针对不同模式作了不同处理，异步模式时即调用了WaitForSingleObject等待函数来设置超时。同步模式时即调用不带重叠结构的ReadFile或WriteFile函数来接收或发送指定量的数据。另外在这介绍下串口虚拟软件vspd，这个软件能模拟在同一台计算机上进行两个串口的通讯，有利于没有实际设备情况下的串口调试。    首先声明，这里的工作线程与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是异步的。

   ACE中的同步机制是轻量级高效的，它不同于MFC中的同步类，MFC中的同步类采用了类继承的方式，而ACE并没有用继承方式，各个不同的锁类是平行的关系，这些类支持相同的接口，即它们的所有公共方法是相同的，因此可被适配用于动态绑定和替换，这种动态绑定是没有虚函数调用开销的,且这些方法代码短小使用了内联实现。应用程序开发者可以通过指定模板实参来使用不同的锁，并可在运行时动态替换。

   ACE中的锁是易于使用的，既有互斥锁(ACE_Mutex)又有读写锁(ACE_RW_Mutex)，这些锁又细分为专门用于线程同步(ACE_Thread_Mutex,ACE_RW_Thread_Mutex)和进程(ACE_Process_Mutex,ACE_RW_Process_Mutex)同步的特定锁。相比MFC高级的是ACE中还提供了递归互斥体(ACE_Token)，可有效地用于某些递归例程。

   ACE中提供了ACE_Lock锁抽象基类和ACE_Adapter_Lock锁适配器模板类，ACE_Adapter_Lock从ACE_Lock继承，实现了动态绑定和替换。另外，ACE还提供了ACE_Atomic_Op模板类，重载了基本的算术运算符，实现了原子化算术运算。