复杂结构体的存取器 [C宏——智者的利刃，愚者的恶梦]

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

在《C宏——智者的利刃，愚者的恶梦! 》一文中，提到了一种使用宏的方式 —— “例1、用C宏，书写代码更简洁”。
《C宏——智者的利刃，愚者的恶梦! 》： http://www.vckbase.com/document/viewdoc/?id=1454
《C宏——智者的利刃，愚者的恶梦! 》： http://blog.vckbase.com/smileonce/archive/2005/03/27/4081.html

本文章分别给出C++和C中不使用宏的实现方式。

 

首先，书写代码更简洁是不是优势？
有兴趣的读者请看看《设计Qt风格的C++API》一文中“便利陷阱” (The Convenience Trap) 一节。
中文： http://blog.csdn.net/TopLanguage/archive/2008/02/21/2111467.aspx
英文： http://doc.trolltech.com/qq/qq13-apis.html

【永远记住代码一次写就，以后须要不断的阅读并理解。】
【Keep in mind that code is written more than once but has to be understood over and over again.】

 

若是真要达到笑笑文中——【mbuf的属性，彻底能够压扁到一个平面上去看】——这个目的，除了宏，也是有其余方法的。

在这里说明一下，笑笑在文中并无给出struct mbuf的完整定义。
我没有linux，Cygwin也删掉了，安装挺麻烦的……
顺藤摸瓜的下载了一部分文件：
http://opengrok.creo.hu/dragonfly/xref/src/sys/sys/mbuf.h
http://opengrok.creo.hu/dragonfly/xref/src/sys/sys/param.h
http://opengrok.creo.hu/dragonfly/xref/src/sys/net/netisr.h
http://opengrok.creo.hu/dragonfly/xref/src/sys/net/netmsg.h
http://opengrok.creo.hu/dragonfly/xref/src/sys/sys/thread.h
http://opengrok.creo.hu/dragonfly/xref/src/sys/sys/msgport.h
企图拼出一个完整的struct mbuf定义，但实在太麻烦，这里就放弃了 ……

因此只用一个简单的例子来讲明如何不使用宏来达到这一目的。
固然，也会说明若是结构体更复杂该如何扩展。

 

/** structure definition */

/* simple Point & Size structure */
typedef struct Point_ {
    int x;
    int y;
} Point;

typedef struct Size_ {
    int width;
    int height;
} Size;

/** complex Rect structrue */
typedef struct Rect_ {
    Point offset;
    Size size;
} Rect;

 

C++方案：

 

namespace cpp {

    class RectAccessor {
    public:
        RectAccessor(Rect& r)
            :x(r.offset.x)
            ,y(r.offset.y)
            ,width(r.size.width)
            ,height(r.size.width)
        {  }
    public:
        int& x;
        int& y;
        int& width;
        int& height;
    };

    void test(int (&arr)[4],Rect* r) {
        RectAccessor ac(*r);
        // 同一平面
        ac.x = arr[0];
        ac.y = arr[1];
        ac.width = arr[2];
        ac.height = arr[3];
        printf("%d %d %d %d\n",ac.x,ac.y,ac.width,ac.height);
    }
}

const怎么办？
（对const的考虑，C++程序员老是比C程序员要多一点，不是吗？）

/** const accessor */
// 再定义一个const存取器不就完了？
class ConstRectAccessor { /**/ };

//若是以为这样名字不统一，很差看，也能够这样
template<bool is_constant>
class RectAccessor;
template<>
class RectAccessor<false> { /* 同上面那个RectAccessor */ };
class RectAccessor<true> { /* 同上面那个ConstRectAccessor */ };

对更复杂的结构体，该方法的扩展是很容易的事情：在构造函数的成员初始化列表里写就是了。

C呢？是否是只能使用宏？固然不是。
C的方案：

 

namespace c {

    typedef union RectAccessor_
    {
        struct S1 {
            int x;
            int y;
            int width;
            int height;
        };
        struct S2 {
            Point offset;
            Size size;
        };
        Rect rect;

    } RectAccessor;

    __declspec(noinline) void test(int (&arr)[4],Rect* r) {
        RectAccessor* ac = (RectAccessor*) r;
        // 同一平面
        ac->x = arr[0];
        ac->y = arr[1];
        ac->width = arr[2];
        ac->height = arr[3];
        printf("%d %d %d %d\n",ac->x,ac->y,ac->width,ac->height);
    }
}

对const, 转型的时候，注意使用合适的指针类型就能够了。

想更复杂的结构体扩展：
若是对上面的方案不理解，甚至对mbuf都不理解，最好仍是老老实实的使用全名。
永远记得，代码读的次数比写的次数多！

上面的方案，是利用了一个特性，叫“匿名联合”还别的什么东东。
含义大概是这样：

union U {
  struct /** anonymous */ {
     t11 v11;
     t12 v12;
     /* more members */
  } /** anonymous */;
  struct /** anonymous */ {
     t21 v21;
     t22 v22;
     /* more members */
  } /** anonymous */;
  /** more structures */
};

/* 那么就能够*/
U u;
u.v11; u.v12; u.v21;

 

经测试，上面两种方案，在VC8 O2优化下，生成的机器码同不使用Accessor 彻底一致。
GCC就没有测试了，看不懂它的汇编……

 

对宏的方案（也就是mbuf.h中提供的）的改进：
简直没法想象！竟然在 头文件 中 定义如此 广泛 的 小写 宏名字！

 

/** mbuf_accessor_define.h */
#define    m_next        m_hdr.mh_next
#define    m_len        m_hdr.mh_len
#define    m_data        m_hdr.mh_data
#define    m_type        m_hdr.mh_type
#define    m_flags        m_hdr.mh_flags
#define    m_nextpkt    m_hdr.mh_nextpkt
#define    m_pkthdr    M_dat.MH.MH_pkthdr
#define    m_ext        M_dat.MH.MH_dat.MH_ext
#define    m_pktdat    M_dat.MH.MH_dat.MH_databuf
#define    m_dat        M_dat.M_databuf

/** mbuf_accessor_undef.h */
#undef    m_next
#undef    m_len
#undef    m_data
#undef    m_type
#undef    m_flags
#undef    m_nextpkt
#undef    m_pkthdr
#undef    m_ext
#undef    m_pktdat
#undef    m_dat

/* 须要的时候 */
#include <mbuf_accessor_define.h>
/* 使用简写 */
/* 使用简写 */
/* 使用简写 */
/* 而后马上取消定义 */
#include <mbuf_accessor_undef.h>

 

PS：C程序员总说C++的语言特性有心智包袱，难道宏就不算心智包袱？

 

物理老师历来都是这么写：              F = M*A;
没见任何一个物理老师会这么写：  F = multiply(M,A);
若是是，请马上和同窗打赌说他是程序员，并且颇有多是C程序员。

hp_int i1,i2,i3;
// ...
数学老师也老是这么写： hp_int icpp = i1 + i2 * i3;

不会有数学老师这么写：
hp_int ic;
hp_assign(&i2,&ic);
hp_multiply(&i3,&ic);
hp_plus(&i1,&ic);

或者这么写：
hp_plus(&i1,hp_multiply(&i3,hp_assgin(&i2,&ic) ) );

（hp —— 高精度，  对矩阵也是一样）

C程序员说，不知道 string s = s1 + s2 + s3;背后作了什么。
C++程序员说，由库决定。
C程序员说，我对库中那些精巧的技术不感兴趣（不熟悉，不肯意学）。
C++程序员说，就对宏技术感兴趣？
C程序员说，宏效率高。
C++程序员说， 若是 string s = s1 + s2 + s3;能够实现得比 strcat(strcat(strcat(....) 效率更高，你信不信？
C++ 程序员再说，若是能够天然的写出hp_int icpp = i1 + i2 * i3;有正确的运算优先级，效率与 hp_plus(&i1,hp_multiply(&i3,hp_assgin(&i2,&ic) ) );等同，你还愿意用后者？
C程序员说，那些实现都是心智包袱，我不喜欢。
C++程序员说，宏算不算心智包袱？你怎么就喜欢了？

总之，这只是一种不肯学习的心态，一种手拿锤子见什么都是钉子的心态。 Linus年纪也不算大……才40岁…… 哎……