• <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>

            陳碩的Blog

            近期微博吐槽言論存檔,涉及“性能優(yōu)化”、C++陋習(xí)等

            寫C++程序的幾個陋習(xí):class 名以大寫 C 開頭,例如 CDate;成員變量以 m_ 開頭;變量采用匈牙利命名法;不知道何時禁用 copy-ctor/assign operator。前三個可能是從MFC那里傳下來的,當(dāng)時C++、class、OO是新玩意兒,要與 C struct 區(qū)分,現(xiàn)在還這么做就土了。C++的成員變量可用特殊命名格式,加下劃線后綴即可(加下劃線前綴是錯的)。但在 Java 里不必模仿 C++ 的這種成員變量命名方式,IDE 可以讓成員變量以不同的顏色顯示,與局部變量區(qū)分,根本無需特殊命名。寫程序就怕把以前的編程經(jīng)驗不加區(qū)分地應(yīng)用到新語言中,寫成四不像,不地道。

            知道禁用 copy-ctor/assign operator 是 C++ 程序員的試金石。在看到一個開源項目時,我一般會先查看其 RAII handle class 是否禁用了 copy-ctor/assign operator(例如 Thread、Mutex、CondVar、Connection),如果沒有,對其第一印象就很差了。

            關(guān)于 class 命名風(fēng)格,Google、LLVM、Mozilla、muduo 都采用 Pascal 風(fēng)格(LikeThis),例如 EventLoop、SudokuSolver 等等。正巧它們也都是用 2 格縮進(jìn)的,可以用 clang-format 自動格式化代碼。

            順便說說我不認(rèn)同的兩個 C++ 教條:1. 用nullptr替換NULL,2. 用cstdio頭文件替換stdio.h。

            因為例如 gettimeofday(&tv, NULL) 這種系統(tǒng)函數(shù)傳個 nullptr 進(jìn)去實在是違和,現(xiàn)在用 NULL 也能達(dá)到 nullptr 的好處,大不了在某個頭文件里define一下就行。這條將來或許會變。

            另外 ctime 頭文件沒定義 std::gmtime_r,而 time.h 定義了 ::gmtime_r。我可不想去背哪些函數(shù)是 C 語言的哪些是 Posix 的,哪些頭文件是 C 語言的哪些是 Posix 的(在Linux下,二者基本不分家)。為了用幾個系統(tǒng)函數(shù)(例如 fcntl() ),我該 include cfcntl 還是 fcntl.h?用線程是 cpthread 還是 pthread.h?我總是記不住 memset() 的參數(shù)順序,因此一般用 bzero() 代替,但是 manpage 說 bzero() 聲明于 strings.h,那我要不要考慮試試 cstrings 呢?何必給自己找麻煩,C++ 標(biāo)準(zhǔn)庫之外的內(nèi)容干脆統(tǒng)一用 .h 頭文件好了。

            性能優(yōu)化?

            有些人常常把“性能”掛在嘴邊,而且其以“提高性能”為理由的“優(yōu)化措施”往往不到點子上,只增加了復(fù)雜性和維護(hù)難度,降低了代碼質(zhì)量。這屬于決策點找偏了。我發(fā)現(xiàn)初學(xué)者往往過分關(guān)注微觀(語句級)性能,比方說關(guān)心 while(true) 和 for(;;) 哪個更快,++i 與 i=i+1 哪個更快,i/=16 和 i >>= 4 哪個快等等,而忽視了現(xiàn)代編譯器的優(yōu)化能力。

            有的人談性能優(yōu)化,一是拿不出具體的合理的性能目標(biāo),只想越快越好,二是不能實際準(zhǔn)確測量驗證性能數(shù)據(jù),憑感覺和過時經(jīng)驗行事。在編碼的時候,遇到兩種做法都可行,決策辦法是憑感覺猜選“性能會更好”的一種,而忽視了其他更重要的因素。可讀性和性能的典型關(guān)系如下圖,有多少場合是值得為了性能而犧牲代碼的可讀性和可維護(hù)性呢?我希望自己的代碼位于第 3 區(qū),而一些人以為自己的代碼是在第 4 區(qū),其實是在第 1 區(qū)。

            read-perf

            能在第 4 區(qū)寫代碼的人屬于鳳毛麟角,有時候你費勁優(yōu)化了半天,結(jié)果新CPU加了幾條指令,直接在硬件層面把問題解決了。現(xiàn)在一些人動不動就要挽起袖子自己寫內(nèi)存池,號稱能提高性能,真當(dāng) Ulrich Drepper 是水貨?(書第 12.2.8 節(jié)“有必要自行定制內(nèi)存分配器嗎”)你打算如何測試內(nèi)存分配器(malloc)的性能?有哪些指標(biāo)?有哪些影響因素需要控制或模擬(比如線程數(shù))?你的測試結(jié)果是否反映實際場景?

            雜項

            有人問為什么我說“poco不是服務(wù)端C++網(wǎng)絡(luò)庫”( http://www.oschina.net/question/12_120943 ),雖然它也提供了reactor?因為它的reactor用的是 Socket::select(),雖然后者包裝了epoll,但看其實現(xiàn)就知道,它每次調(diào)用都會創(chuàng)建并銷毀 epoll fd,然后重建整個watch list,沒有哪個服務(wù)端網(wǎng)絡(luò)庫會這么做。

            嗯,世界上有兩種網(wǎng)絡(luò)編程:網(wǎng)絡(luò)編程和Windows網(wǎng)絡(luò)編程。

            posted on 2013-08-12 13:54 陳碩 閱讀(3780) 評論(6)  編輯 收藏 引用

            評論

            # re: 近期微博吐槽言論存檔,涉及&ldquo;性能優(yōu)化&rdquo;、C++陋習(xí)等 2013-08-13 10:11 Test

            一家之言  回復(fù)  更多評論   

            # re: 近期微博吐槽言論存檔,涉及&ldquo;性能優(yōu)化&rdquo;、C++陋習(xí)等 2013-08-15 14:48 小夜

            圖很形象,贊一個。
            對文中的觀點很贊同,本來C/C++就已經(jīng)夠復(fù)雜了,再加上額外的教條的東西,只會加重使用者的負(fù)擔(dān)。  回復(fù)  更多評論   

            # re: 近期微博吐槽言論存檔,涉及&ldquo;性能優(yōu)化&rdquo;、C++陋習(xí)等 2013-08-15 16:39 其實俺不是什么所謂的壞人

            nullptr用于區(qū)別 int和指針類型的重載  回復(fù)  更多評論   

            # re: 近期微博吐槽言論存檔,涉及&ldquo;性能優(yōu)化&rdquo;、C++陋習(xí)等 2013-08-16 00:09 陳碩

            @其實俺不是什么所謂的壞人
            我文中寫了“現(xiàn)在用 NULL 也能達(dá)到 nullptr 的好處,大不了在某個頭文件里define一下就行。”

            不信在g++下試一下:

            #include <stdio.h>

            void foo(int)
            {
            printf("int");
            }

            void foo(char*)
            {
            printf("char*");
            }

            int main()
            {
            foo(NULL);
            }

            $ g++ null.cc
            null.cc: In function 'int main()':
            null.cc:15:11: error: call of overloaded 'foo(NULL)' is ambiguous
            null.cc:15:11: note: candidates are:
            null.cc:3:6: note: void foo(int)
            null.cc:8:6: note: void foo(char*)
              回復(fù)  更多評論   

            # re: 近期微博吐槽言論存檔,涉及&ldquo;性能優(yōu)化&rdquo;、C++陋習(xí)等 2013-08-19 11:43 tb

            有者改 無者加銘  回復(fù)  更多評論   

            # re: 近期微博吐槽言論存檔,涉及&ldquo;性能優(yōu)化&rdquo;、C++陋習(xí)等 2013-08-30 11:26 陳龍

            關(guān)于“微觀性能”, ++i、i++等,我覺得這些雖微小,但可以看出一個程序員的素養(yǎng)與習(xí)慣問題,因為這些都是隨手可做的。  回復(fù)  更多評論   


            只有注冊用戶登錄后才能發(fā)表評論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            <2013年10月>
            293012345
            6789101112
            13141516171819
            20212223242526
            272829303112
            3456789

            導(dǎo)航

            統(tǒng)計

            常用鏈接

            隨筆分類

            隨筆檔案

            相冊

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            无码国内精品久久人妻蜜桃| 久久免费视频观看| 久久久久久久久久久| 色欲久久久天天天综合网精品| 国产精品久久久久久吹潮| 久久久久久a亚洲欧洲aⅴ| 日韩久久无码免费毛片软件| 久久中文骚妇内射| 精品无码久久久久久久久久| 香蕉久久av一区二区三区 | 久久久久亚洲AV无码专区桃色 | 偷偷做久久久久网站| 久久亚洲国产欧洲精品一| 亚洲AV日韩精品久久久久久久| 成人a毛片久久免费播放| 国产精品美女久久久久久2018| 一本综合久久国产二区| 久久成人永久免费播放| 99re久久精品国产首页2020| 日本精品久久久久影院日本 | 久久久久国产一级毛片高清版| 亚洲va久久久噜噜噜久久狠狠| 欧美激情精品久久久久久久九九九 | 国产激情久久久久久熟女老人 | 久久香蕉一级毛片| 国产69精品久久久久777| 99久久99久久精品国产片果冻| 久久亚洲中文字幕精品一区四| 久久国产精品久久| 777久久精品一区二区三区无码 | 日韩精品无码久久一区二区三| 国产成人久久久精品二区三区| 日本三级久久网| 91性高湖久久久久| 久久精品中文字幕有码| 日本高清无卡码一区二区久久| 人人狠狠综合88综合久久| 亚洲国产成人精品久久久国产成人一区二区三区综 | 国产成人久久精品一区二区三区| 久久人爽人人爽人人片AV| 精品无码久久久久久尤物|