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

            近期微博吐槽言論存檔,涉及“性能優化”、C++陋習等

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

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

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

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

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

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

            性能優化?

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

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

            read-perf

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

            雜項

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

            嗯,世界上有兩種網絡編程:網絡編程和Windows網絡編程。

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

            評論

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

            一家之言  回復  更多評論   

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

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

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

            nullptr用于區別 int和指針類型的重載  回復  更多評論   

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

            @其實俺不是什么所謂的壞人
            我文中寫了“現在用 NULL 也能達到 nullptr 的好處,大不了在某個頭文件里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*)
              回復  更多評論   

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

            有者改 無者加銘  回復  更多評論   

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

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

            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            導航

            統計

            常用鏈接

            隨筆分類

            隨筆檔案

            相冊

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            久久久这里只有精品加勒比| 亚洲&#228;v永久无码精品天堂久久 | 久久国产成人精品国产成人亚洲| 亚洲AV无码久久| 久久精品一区二区三区AV| 四虎影视久久久免费| 欧美亚洲国产精品久久久久| 色偷偷88欧美精品久久久| 欧美久久综合九色综合| 久久影视综合亚洲| 久久国产亚洲精品| 2021国产精品午夜久久| 久久中文字幕人妻熟av女| 亚洲国产美女精品久久久久∴| 国内高清久久久久久| 久久久噜噜噜www成人网| 久久国产精品久久久| 亚洲国产成人久久精品影视| 国产高潮国产高潮久久久91 | 久久天堂AV综合合色蜜桃网| 精品久久久久久国产潘金莲| 国产69精品久久久久777| 亚洲精品国产成人99久久| 精品水蜜桃久久久久久久| 久久e热在这里只有国产中文精品99| 日本久久久久久久久久| 久久无码国产专区精品| 久久精品国产亚洲av日韩| 久久这里只精品国产99热| 亚洲AⅤ优女AV综合久久久| 亚洲中文字幕久久精品无码APP| 久久国产乱子伦免费精品| 国产成人无码精品久久久久免费| 亚洲国产精品成人AV无码久久综合影院| 国产精品中文久久久久久久| 精品久久久久久久久午夜福利| 97久久精品人人澡人人爽| 狠狠色婷婷久久综合频道日韩| 久久777国产线看观看精品| 午夜精品久久久久| 色综合久久久久|