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

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

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

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

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

            另外 ctime 頭文件沒定義 std::gmtime_r,而 time.h 定義了 ::gmtime_r。我可不想去背哪些函數(shù)是 C 語言的哪些是 Posix 的,哪些頭文件是 C 語言的哪些是 Posix 的(在Linux下,二者基本不分家)。為了用幾個(gè)系統(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)化措施”往往不到點(diǎn)子上,只增加了復(fù)雜性和維護(hù)難度,降低了代碼質(zhì)量。這屬于決策點(diǎn)找偏了。我發(fā)現(xiàn)初學(xué)者往往過分關(guān)注微觀(語句級(jí))性能,比方說關(guān)心 while(true) 和 for(;;) 哪個(gè)更快,++i 與 i=i+1 哪個(gè)更快,i/=16 和 i >>= 4 哪個(gè)快等等,而忽視了現(xiàn)代編譯器的優(yōu)化能力。

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

            read-perf

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

            雜項(xiàng)

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

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

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

            評(píng)論

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

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

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

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

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

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

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

            @其實(shí)俺不是什么所謂的壞人
            我文中寫了“現(xiàn)在用 NULL 也能達(dá)到 nullptr 的好處,大不了在某個(gè)頭文件里define一下就行?!?br>
            不信在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ù)  更多評(píng)論   

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

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

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

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


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


            <2013年8月>
            28293031123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            導(dǎo)航

            統(tǒng)計(jì)

            常用鏈接

            隨筆分類

            隨筆檔案

            相冊(cè)

            搜索

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            国产精品无码久久综合| 久久精品国产亚洲AV嫖农村妇女| 久久99国产精品久久99果冻传媒| 7国产欧美日韩综合天堂中文久久久久 | 久久夜色精品国产www| 国产69精品久久久久777| 伊人久久大香线蕉综合影院首页| 久久www免费人成看国产片| 精品久久久久久亚洲| 欧美成a人片免费看久久| 久久中文骚妇内射| 7777精品久久久大香线蕉| 久久久精品一区二区三区| 99久久久精品| 亚洲中文字幕无码久久综合网| 久久99国产精品二区不卡| 久久久久久曰本AV免费免费| 一本色道久久88综合日韩精品| 久久久中文字幕日本| 国产成人久久精品区一区二区| 亚洲日本久久久午夜精品| 伊人久久亚洲综合影院| 久久综合综合久久狠狠狠97色88| 久久精品国产免费观看| 人人狠狠综合久久亚洲高清| 久久亚洲国产精品123区| 久久久精品免费国产四虎| 亚洲日韩中文无码久久| 久久人人爽人人爽人人片av麻烦 | 久久国产成人午夜AV影院| 久久er热视频在这里精品| 亚洲欧洲日产国码无码久久99| 精品久久久久久国产潘金莲| 久久精品青青草原伊人| 午夜视频久久久久一区| 色偷偷88欧美精品久久久| 久久免费国产精品| 亚洲精品久久久www| 久久99热这里只有精品66| 99久久精品日本一区二区免费| 国产激情久久久久久熟女老人|