• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

                posts - 16,  comments - 34,  trackbacks - 0

                在《C宏——智者的利刃,愚者的惡夢! 》一文中,提到了一種使用宏的方式 —— “例一、用C宏,書寫代碼更簡潔”。
                《C宏——智者的利刃,愚者的惡夢! 》: http://www.vckbase.com/document/viewdoc/?id=1454
                《C宏——智者的利刃,愚者的惡夢! 》: http://blog.vckbase.com/smileonce/archive/2005/03/27/4081.html

                本文章分別給出C++和C中不使用宏的實現(xiàn)方式。


                 

                首先,書寫代碼更簡潔是否是優(yōu)點?
                有興趣的讀者請看看《設計Qt風格的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

                【永遠記住代碼一次寫就,之后需要不斷的閱讀并理解。】
                【Keep in mind that code is written more than once but has to be understood over and over again.】


                 

                如果真要達到笑笑文中——【mbuf的屬性,完全可以壓扁到一個平面上去看】——這個目的,除了宏,也是有其他方法的。

                在這里說明一下,笑笑在文中并沒有給出struct mbuf的完整定義。
                我沒有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
                企圖拼出一個完整的struct mbuf定義,但實在太麻煩,這里就放棄了 ……

                所以只用一個簡單的例子來說明如何不使用宏來達到這一目的。
                當然,也會說明如果結構體更復雜該如何擴展。


                 

                結構體定義:




                C++方案:

                 

                C++方案


                const怎么辦?
                (對const的考慮,C++程序員總是比C程序員要多一點,不是嗎?)

                const accessor


                對更復雜的結構體,該方法的擴展是很容易的事情:在構造函數的成員初始化列表里寫就是了。



                C呢?是不是只能使用宏?當然不是。
                C的方案:

                 

                union


                對const, 轉型的時候,注意使用合適的指針類型就可以了。

                想更復雜的結構體擴展:
                如果對上面的方案不理解,甚至對mbuf都不理解,最好還是老老實實的使用全名。
                永遠記得,代碼讀的次數比寫的次數多!

                上面的方案,是利用了一個特性,叫“匿名聯(lián)合”還別的什么東東。
                含義大概是這樣:

                anonymous

                 



                經測試,上面兩種方案,在VC8 O2優(yōu)化下,生成的機器碼同不使用Accessor完全一致
                GCC就沒有測試了,看不懂它的匯編……

                 


                對宏的方案(也就是mbuf.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;可以實現(xiàn)得比 strcat(strcat(strcat(....) 效率更高,你信不信?
                C++程序員再說,如果可以自然的寫出hp_int icpp = i1 + i2 * i3;有正確的運算優(yōu)先級,效率與hp_plus(&i1,hp_multiply(&i3,hp_assgin(&i2,&ic) ) );等同,你還愿意用后者?
                C程序員說,那些實現(xiàn)都是心智包袱,我不喜歡。
                C++程序員說,宏算不算心智包袱?你怎么就喜歡了?


                總之,這只是一種不愿學習的心態(tài),一種手拿錘子見什么都是釘子的心態(tài)。
                Linus年紀也不算大……才40歲…… 哎……

                posted on 2009-02-19 21:48 OwnWaterloo 閱讀(1997) 評論(4)  編輯 收藏 引用

                FeedBack:
                # re: 復雜結構體的存取器
                2009-02-21 17:31 | Anonymous
                笑死人了,這也叫解決方案?

                真是無知者無畏啊。
                  回復  更多評論
                  
                # re: 復雜結構體的存取器
                2009-02-21 20:07 | OwnWaterloo
                @Anonymous
                閣下有何高見? 還是說,只有說屁話的本事?  回復  更多評論
                  
                # re: 復雜結構體的存取器
                2009-02-24 16:14 | 007
                8錯 收藏了  回復  更多評論
                  
                # re: 復雜結構體的存取器
                2009-02-25 23:17 | Chipset
                宏,不能遞歸、不能繼承、不能重載,這到沒有什么。關鍵是重名問題最要命,程序小當然沒什么,程序大了很多人開發(fā),不同的人維護和升級(有辭職的新招來的人員變動),最終結果可想而知。

                “C宏——智者的利刃,愚者的惡夢! ”怎么能這么說話呢?
                Bjarne Stroustrup在擔任AT&T大規(guī)模程序設計的負責人期間發(fā)現(xiàn),將近50%的問題由宏引起...,難道這些人都是愚者?汗...~~  回復  更多評論
                  
                <2009年2月>
                25262728293031
                1234567
                891011121314
                15161718192021
                22232425262728
                1234567

                常用鏈接

                留言簿(8)

                隨筆檔案(16)

                鏈接

                搜索

                •  

                積分與排名

                • 積分 - 198665
                • 排名 - 134

                最新隨筆

                最新評論

                閱讀排行榜

                評論排行榜

                狠狠狠色丁香婷婷综合久久五月| 91精品国产乱码久久久久久| 久久精品国产精品亜洲毛片 | 久久综合五月丁香久久激情| 国产成人无码精品久久久性色| 久久久久99精品成人片试看| 久久精品国产亚洲Aⅴ香蕉| 国内精品人妻无码久久久影院导航| 精品久久久久久无码专区| 色婷婷综合久久久久中文字幕| 国产亚洲综合久久系列| 亚洲午夜福利精品久久| 国产精品综合久久第一页| AAA级久久久精品无码片| 国产免费久久精品99re丫y| 亚洲国产精品无码久久青草 | 久久男人AV资源网站| 久久久综合九色合综国产| 精品国产一区二区三区久久| 日韩精品久久久久久免费| 久久久久人妻一区精品色| 久久狠狠高潮亚洲精品| 国产成人久久777777| 久久久久亚洲AV综合波多野结衣 | 97精品伊人久久久大香线蕉| 91麻豆精品国产91久久久久久| 久久精品无码一区二区app| 国产精品久久久久久久久软件 | 色偷偷88欧美精品久久久| 欧美黑人激情性久久| 国内精品久久久久久久97牛牛| 久久精品国产亚洲沈樵| 中文字幕热久久久久久久| 91精品国产91久久久久久| 久久精品桃花综合| 伊人久久精品影院| 99久久无色码中文字幕| 久久国产精品一国产精品金尊| 亚洲国产精品嫩草影院久久 | 93精91精品国产综合久久香蕉| 东方aⅴ免费观看久久av|