在《C宏——智者的利刃，愚者的惡夢(mèng)! 》一文中，提到了一種使用宏的方式 —— “例一、用C宏，書(shū)寫(xiě)代碼更簡(jiǎn)潔”。
《C宏——智者的利刃，愚者的惡夢(mèng)! 》： http://www.vckbase.com/document/viewdoc/?id=1454
《C宏——智者的利刃，愚者的惡夢(mèng)! 》： http://blog.vckbase.com/smileonce/archive/2005/03/27/4081.html
本文章分別給出C++和C中不使用宏的實(shí)現(xiàn)方式。
?
首先，書(shū)寫(xiě)代碼更簡(jiǎn)潔是否是優(yōu)點(diǎn)？
有興趣的讀者請(qǐng)看看《設(shè)計(jì)Qt風(fēng)格的C++API》一文中“便利陷阱” (The Convenience Trap) 一節(jié)。
中文： http://blog.csdn.net/TopLanguage/archive/2008/02/21/2111467.aspx
英文： http://doc.trolltech.com/qq/qq13-apis.html
【永遠(yuǎn)記住代碼一次寫(xiě)就，之后需要不斷的閱讀并理解?！?br />【Keep in mind that code is written more than once but has to be understood over and over again.】
?
如果真要達(dá)到笑笑文中——【mbuf的屬性，完全可以壓扁到一個(gè)平面上去看】——這個(gè)目的，除了宏，也是有其他方法的。
在這里說(shuō)明一下，笑笑在文中并沒(méi)有給出struct mbuf的完整定義。
我沒(méi)有l(wèi)inux，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
企圖拼出一個(gè)完整的struct mbuf定義，但實(shí)在太麻煩，這里就放棄了 ……
所以只用一個(gè)簡(jiǎn)單的例子來(lái)說(shuō)明如何不使用宏來(lái)達(dá)到這一目的。
當(dāng)然，也會(huì)說(shuō)明如果結(jié)構(gòu)體更復(fù)雜該如何擴(kuò)展。
?
結(jié)構(gòu)體定義：
/**/
/*
*?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++方案：
?
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怎么辦？
（對(duì)const的考慮，C++程序員總是比C程序員要多一點(diǎn)，不是嗎？）
const accessor
/**//**?const?accessor?*/
//?再定義一個(gè)const存取器不就完了？
class?ConstRectAccessor?{?/**//**/?};
//如果覺(jué)得這樣名字不統(tǒng)一，不好看，也可以這樣
template<bool?is_constant>
class?RectAccessor;
template<>
class?RectAccessor<false>?{?/**//*?同上面那個(gè)RectAccessor?*/?};
class?RectAccessor<true>?{?/**//*?同上面那個(gè)ConstRectAccessor?*/?};
對(duì)更復(fù)雜的結(jié)構(gòu)體，該方法的擴(kuò)展是很容易的事情：在構(gòu)造函數(shù)的成員初始化列表里寫(xiě)就是了。
C呢？是不是只能使用宏？當(dāng)然不是。
C的方案：
?
union
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);
????}
}
對(duì)const, 轉(zhuǎn)型的時(shí)候，注意使用合適的指針類(lèi)型就可以了。
想更復(fù)雜的結(jié)構(gòu)體擴(kuò)展：
如果對(duì)上面的方案不理解，甚至對(duì)mbuf都不理解，最好還是老老實(shí)實(shí)的使用全名。
永遠(yuǎn)記得，代碼讀的次數(shù)比寫(xiě)的次數(shù)多！
上面的方案，是利用了一個(gè)特性，叫“匿名聯(lián)合”還別的什么東東。
含義大概是這樣：
anonymous
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;
?
經(jīng)測(cè)試，上面兩種方案，在VC8 O2優(yōu)化下，生成的機(jī)器碼同不使用Accessor
完全一致。
GCC就沒(méi)有測(cè)試了，看不懂它的匯編……
?
對(duì)宏的方案（也就是mbuf.h中提供的）的改進(jìn)：
簡(jiǎn)直無(wú)法想象！居然在
頭文件 中
定義如此
普遍 的
小寫(xiě)宏名字！
?
宏改進(jìn)方案：
/**//**?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
/**//*?需要的時(shí)候?*/
#include?<mbuf_accessor_define.h>
/**//*?使用簡(jiǎn)寫(xiě)?*/
/**//*?使用簡(jiǎn)寫(xiě)?*/
/**//*?使用簡(jiǎn)寫(xiě)?*/
/**//*?然后立刻取消定義?*/
#include?<mbuf_accessor_undef.h> ?
PS：C程序員總說(shuō)C++的語(yǔ)言特性有心智包袱，難道宏就不算心智包袱？
?
物理老師從來(lái)都是這么寫(xiě)：???????????? ?F = M*A;
沒(méi)見(jiàn)任何一個(gè)物理老師會(huì)這么寫(xiě)：? F = multiply(M,A);
如果是，請(qǐng)立刻和同學(xué)打賭說(shuō)他是程序員，而且很有可能是C程序員。
hp_int i1,i2,i3;
// ...
數(shù)學(xué)老師也總是這么寫(xiě)： hp_int icpp = i1 + i2 * i3;
不會(huì)有數(shù)學(xué)老師這么寫(xiě)：
hp_int ic;
hp_assign(&i2,&ic);
hp_multiply(&i3,&ic);
hp_plus(&i1,&ic);
或者這么寫(xiě)：
hp_plus(&i1,hp_multiply(&i3,hp_assgin(&i2,&ic) ) );
（hp —— 高精度，? 對(duì)矩陣也是同樣）
C程序員說(shuō)，不知道 string s = s1 + s2 + s3;背后做了什么。
C++程序員說(shuō)，由庫(kù)決定。
C程序員說(shuō)，我對(duì)庫(kù)中那些精巧的技術(shù)不感興趣（不熟悉，不愿意學(xué)）。
C++程序員說(shuō)，就對(duì)宏技術(shù)感興趣？
C程序員說(shuō)，宏效率高。
C++程序員說(shuō)， 如果 string s = s1 + s2 + s3;可以實(shí)現(xiàn)得比 strcat(strcat(strcat(....) 效率更高，你信不信？
C++程序員再說(shuō)，如果可以自然的寫(xiě)出hp_int icpp = i1 + i2 * i3;有正確的運(yùn)算優(yōu)先級(jí)，效率與hp_plus(&i1,hp_multiply(&i3,hp_assgin(&i2,&ic) ) );等同，你還愿意用后者？
C程序員說(shuō)，那些實(shí)現(xiàn)都是心智包袱，我不喜歡。
C++程序員說(shuō)，宏算不算心智包袱？你怎么就喜歡了？
總之，這只是一種不愿學(xué)習(xí)的心態(tài)，一種手拿錘子見(jiàn)什么都是釘子的心態(tài)。
Linus年紀(jì)也不算大……才40歲…… 哎……
posted on 2009-02-19 21:48
OwnWaterloo 閱讀(90)
評(píng)論(0) ?
編輯?
收藏引用