C宏——智者的利刃，愚者的恶梦!

àì夳堔傛蜴生んèń 2022-08-07 05:51 92阅读 0赞

[http://www.vckbase.com/document/viewdoc/?id=1454][http_www.vckbase.com_document_viewdoc_id_1454]

作者：[乾坤一笑][Link 1]

本文出自 [乾坤一笑 的Blog文章][Link 1]  
  
　　水平不高不低的C++程序员最喜欢挂在嘴上的一句话就是：C宏，万恶之首，错误的开端，应该被废弃。  
　　请注意，我用了一句不敬的修饰语“水平不高不低的”。为什么这么说？因为水平低都插不上话，都在在静静地听老前辈布道呢。水平高的，比如Bane Stroustrup老人家，也只是说若干种场合下C++语言能够提供比C macro更好的解决方案，而没有完全否定C macro的价值。但是话就怕传来传去，一传就走样。久而久之，就被传成上面那句话。其实说来也很好笑：java程序员经常说java比C++好，说C++手动释放内存老搞内存泄漏；C++程序员便反驳说，那是你水平低不会用。但是谈到C宏，水平不高不低的C++程序员居然也走java的老路了——明明是自己不会用，自己知道的少，却把责任推卸到C宏上。你自己笨我管不着，但是错误的言论如果误导后人就不好了吧。:)  
　　本文就举几个简单的使用C宏的例子，如果这些例子用C++不用宏的语法能更好的解决，那么你一定要回复blog告诉我，这样下次我就不乱说话了。否则，笑笑很生气，后果很严重。:)  
  
例一、用C宏，书写代码更简洁这段代码写网络程序的朋友都很眼熟，是Net/3中mbuf的实现。

struct mbuf
    {
        struct m_hdr mhdr;
        union {
            struct 
            {
                struct pkthdr MH_pkthdr; /* M_PKTHDR set */
                union 
                {
                    struct m_ext MH_ext; /* M_EXT set */
                    char MH_databuf[MHLEN];
                } MH_dat;
            } MH;
            char M_databuf[MLEN];        /* !M_PKTHER, !M_EXT*/
        } M_dat;
    };

上面的代码，假如我想访问最里层的MH\_databuf，那么我必须写M\_dat.MH.MH\_dat.MH\_databuf; 这是不是很长，很难写呀？这样的代码阅读起来也不明了。其实，对于MH\_pkthdr、MH\_ext、MH\_databuf来说，虽然不是在一个结构层次上，但是如果我们站在mbuf之外来看，它们都是mbuf的属性，完全可以压扁到一个平面上去看。所以，源码中有这么一组宏：

#define m_next      m_hdr.mh_next
    #define m_len       m_hdr.mh_len
    #define m_data      m_hdr.mh_data
    ... ...
    #define m_pkthdr    M_dat.MH.MH_pkthdr
    #define m_pktdat    M_dat.MH.MH_dat.MH_databuf
    ... ...

这样写起代码来，是不是很精练呢！  
  
例二、用C宏，实现跨平台和编译器的需要这方面的例子太好举了，一举一大摞，就从VC的库源码中随意copy一段出来吧。

#ifndef _CRTAPI1
    #if _MSC_VER >= 800 && _M_IX86 >= 300
    #define _CRTAPI1 __cdecl
    #else  /* _MSC_VER >= 800 && _M_IX86 >= 300 */
    #define _CRTAPI1
    #endif  /* _MSC_VER >= 800 && _M_IX86 >= 300 */
    #endif  /* _CRTAPI1 */
    
    #ifndef _SIZE_T_DEFINED
    typedef unsigned int size_t;
    #define _SIZE_T_DEFINED
    #endif  /* _SIZE_T_DEFINED */
    
    #ifndef _MAC
    #ifndef _WCHAR_T_DEFINED
    typedef unsigned short wchar_t;
    #define _WCHAR_T_DEFINED
    #endif  /* _WCHAR_T_DEFINED */
    #endif  /* _MAC */
     
    #ifndef _NLSCMP_DEFINED
    #define _NLSCMPERROR    2147483647  /* currently == INT_MAX */
    #define _NLSCMP_DEFINED
    #endif  /* _NLSCMP_DEFINED */

请问，这些指示宏如何取代呢？如果真的是没有了这些宏，实现起来就更麻烦了吧。  
  
例三、用C宏，自动生成代码这方面的例子也是多得很，不过有鉴于很多朋友不用很多编译器，不做嵌入式的开发，我就举个win平台的例子吧。我们知道MFC实现了windows的消息映射，比如：

ON_COMMAND(IDM_ABOUT, OnAbout)
    ON_COMMAND(IDM_FILENEW, OnFileNew)

它是如何实现的IDM\_ABOUT和OnAbout的关联的呢？这要用到几个宏。

#define DECLARE_MESSAGE_MAP() /
    private: /
     static const AFX_MSGMAP_ENTRY _messageEntries[]; /
    protected: /
     static AFX_DATA const AFX_MSGMAP messageMap; /
     virtual const AFX_MSGMAP* GetMessageMap() const; /
    
    #define BEGIN_MESSAGE_MAP(theClass, baseClass) /
     const AFX_MSGMAP* theClass::GetMessageMap() const /
      { return &theClass::messageMap; } /
     AFX_COMDAT AFX_DATADEF const AFX_MSGMAP theClass::messageMap = /
     { &baseClass::messageMap, &theClass::_messageEntries[0] }; /
     AFX_COMDAT const AFX_MSGMAP_ENTRY theClass::_messageEntries[] = /
     { /
    
     #define ON_COMMAND(id, memberFxn) /
            { WM_COMMAND, 0, (WORD)id, (WORD)id, AfxSig_vv, (AFX_PMSG)memberFxn },
    
     #define END_MESSAGE_MAP() /
      {0, 0, 0, 0, AfxSig_end, (AFX_PMSG)0 } /
     }; /
    #define DECLARE_MESSAGE_MAP() /
    private: /
     static const AFX_MSGMAP_ENTRY _messageEntries[]; /
    protected: /
     static AFX_DATA const AFX_MSGMAP messageMap; /
     virtual const AFX_MSGMAP* GetMessageMap() const; /
    
    #define BEGIN_MESSAGE_MAP(theClass, baseClass) /
     const AFX_MSGMAP* theClass::GetMessageMap() const /
      { return &theClass::messageMap; } /
     AFX_COMDAT AFX_DATADEF const AFX_MSGMAP theClass::messageMap = /
     { &baseClass::messageMap, &theClass::_messageEntries[0] }; /
     AFX_COMDAT const AFX_MSGMAP_ENTRY theClass::_messageEntries[] = /
     { /
    
     #define ON_COMMAND(id, memberFxn) /
            { WM_COMMAND, 0, (WORD)id, (WORD)id, AfxSig_vv, (AFX_PMSG)memberFxn },
    
     #define END_MESSAGE_MAP() /
      {0, 0, 0, 0, AfxSig_end, (AFX_PMSG)0 } /
     }; /

嘿嘿，就这么几个宏，就构造出一个消息数组来。  
  
例四、用C宏，智者思维的火花说了半天了，嘴皮子都干了，举个例子大家轻松一下——看看人家老外是怎么用宏的。这个例子摘自《C专家编程》。 根据位模式构建图形图标（icon）或者图形(glyph)，是一种小型的位模式映射于屏幕产生的图像。一个位代表图像上的一个像素。如果一个位被设置，那么它所代表的像素就是“亮”的。如果一个位被清除，那么它所代表的像素就是“暗”的。所以，一系列的整数值能够用于为图像编码。类似Iconedit这样的工具就是用于绘图的，他们所输出的是一个包含一系列整型数的ASCII文件，可以被一个窗口程序所包含。它所存在的问题是程序中的图标只是一串十六进制数。在C语言中，典型的16X16的黑白图形可能如下：

static unsigned short stopwatch[] = {
    0x07C6,
    0x1FF7,
    0x383B,
    0x600C,
    0x600C,
    0xC006,
    0xC006,
    0xDF06,
    0xC106,
    0xC106,
    0x610C,
    0x610C,
    0x3838,
    0x1FF0,
    0x07C0,
    0x0000
    };

正如所看到的那样，这些C语言常量并未有提供有关图形实际模样的任何线索。这里有一个惊人的\#define定义的优雅集合，允许程序建立常量使它们看上去像是屏幕上的图形。

#define X )*2+1
    #define _ )*2
    #define s ((((((((((((((((0 /* For building glyphs 16 bits wide */

定义了它们之后，只要画所需要的图标或者图形等，程序会自动创建它们的十六进制模式。使用这些宏定义，程序的自描述能力大大加强，上面这个例子可以转变为：

static unsigned short stopwatch[] =
    {
    s _ _ _ _ _ X X X X X _ _ _ X X _ ,
    s _ _ _ X X X X X X X X X _ X X X ,
    s _ _ X X X _ _ _ _ _ X X X _ X X ,
    s _ X X _ _ _ _ _ _ _ _ _ X X _ _ ,
    s _ X X _ _ _ _ _ _ _ _ _ X X _ _ ,
    s X X _ _ _ _ _ _ _ _ _ _ _ X X _ ,
    s X X _ _ _ _ _ _ _ _ _ _ _ X X _ ,
    s X X _ X X X X X _ _ _ _ _ X X _ ,
    s X X _ _ _ _ _ X _ _ _ _ _ X X _ ,
    s X X _ _ _ _ _ X _ _ _ _ _ X X _ ,
    s _ X X _ _ _ _ X _ _ _ _ X X _ _ ,
    s _ X X _ _ _ _ X _ _ _ _ X X _ _ ,
    s _ _ X X X _ _ _ _ _ X X X _ _ _ ,
    s _ _ _ X X X X X X X X X _ _ _ _ ,
    s _ _ _ _ _ X X X X X _ _ _ _ _ _ ,
    s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
    };

显然，与前面的代码相比，它的意思更为明显。标准的C语言具有八进制、十进制和十六进制常量，但没有二进制常量，否则的话倒是一种更为简单的绘制图形模式的方法。  
　　如果抓住书的右上角，并斜这看这一页，可能会猜测这是一个用于流行窗口系统的“cursor busy”小秒表图形。我是在几年前从Usenet comp.lang.c新闻组学到这个技巧的。  
  
　　千万不要忘了在绘图结束后清除这些宏定义，否这很可能会给你后面的代码带来不可预测的后果。  
  
　　好了，今天的废话就到这里了。水能载舟，亦能覆舟，把握好手中的双刃剑，让它好好的为你服务吧，别割破了手。:)

[http_www.vckbase.com_document_viewdoc_id_1454]: http://www.vckbase.com/document/viewdoc/?id=1454
[Link 1]: http://blog.vckbase.com/smileonce/archive/2005/03/27/4081.html