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

            無我

            讓內(nèi)心永遠(yuǎn)燃燒著偉大的光明的精神之火!
            靈活的思考,嚴(yán)謹(jǐn)?shù)膶崿F(xiàn)
            豪邁的氣魄、頑強的意志和周全的思考

            用memcpy替代strcpy/strncpy

                  首先描述一下三個相關(guān)函數(shù)strcpy/strncpy、memcpy和memmove的意義。

                  眾所周知的,strcpy/strncpy和memcpy都是用于從一塊內(nèi)存復(fù)制一段連續(xù)的數(shù)據(jù)到另一塊內(nèi)存,區(qū)別是終結(jié)標(biāo)識不同。strcpy會比較每個字符是否為'\0'以判定是否繼續(xù)復(fù)制,而memcpy就不管內(nèi)存數(shù)據(jù)內(nèi)容,確定復(fù)制指定的長度(不討論源串有錯誤或者目的空間不夠等出錯的情況)。所以這兩者在作用上是可以共通的,我想這兩個函數(shù)最大的區(qū)別只能說是語義上的區(qū)別。而用法上,strcpy只能針對字符串,memcpy卻沒有這個限制,用memcpy(char*pDest,char*pSource,strlen(pSource))完全能替代strcpy的功能。

                  而后面兩個mem系列函數(shù),主要區(qū)別在memcpy對于重疊內(nèi)存的復(fù)制支持不太好。例如對char a[10]操作的話,memcpy(a, a + 3, 5)這樣的,源數(shù)據(jù)是a+3到a+7,目標(biāo)位置是a到a+5,操作區(qū)域有重復(fù),則應(yīng)該用memmove。

                  好了,說明了這三個函數(shù)的作用,就進(jìn)入本文討論的正題:用memcpy替代strcpy/strncpy!

                  首先,從功能上來說,上文已經(jīng)討論過了,用memcpy(char*pDest,char*pSource,strlen(pSource))完全能替代strcpy的功能。之所以倡導(dǎo)這種用法,在于用memcpy函數(shù)不僅功能上比strcpy/strncpy更強大,關(guān)鍵在于前者效率要高很多!盡管沒有這兩個函數(shù)的源代碼,但是單從分析上,strcpy\strncpy需要在每一步操作時都要比較字符是否為'\0',而memcpy完全不需要,甚至有更快的指令來優(yōu)化塊復(fù)制,所以效率肯定高很多。事實上,測試結(jié)果也是這樣,測試程序如下:

             

            #include <string.h>
            #include 
            <windows.h>

            int main(void)
            {
                
            char * pch = "常常有人問:我想學(xué)習(xí)內(nèi)核,需要什么基礎(chǔ)嗎?LinusTorvalds本人是這樣回答的:你必須使用過Linux。這個……還是有點太泛了吧,我想下面幾個基礎(chǔ)可能還是需要的,盡管不一定必需:1,關(guān)于操作系統(tǒng)理論的最初級的知識。不需要通讀并理解《操作系統(tǒng)概念》《現(xiàn)代操作系統(tǒng)》等巨著,但總要知道分時(time-shared)和實時(real-time)的區(qū)別是什么,進(jìn)程是個什么東西,CPU和系統(tǒng)總線、內(nèi)存的關(guān)系(很粗略即可),等等。2,關(guān)于C語言。不需要已經(jīng)很精通C語言,只要能熟練編寫C程序,能看懂鏈表、散列表等數(shù)據(jù)結(jié)構(gòu)的C實現(xiàn),用過gcc編譯器,就可以了。當(dāng)然,如果已經(jīng)精通C語言顯然是大占便宜的。3,關(guān)于CPU的知識。這塊兒可以在學(xué)習(xí)內(nèi)核過程中補,但這樣的話你就需要看講解很詳細(xì)的書,比方后面將會提到的《情景分析》。你是否熟悉Intel80386CPU?嘗試著回答這幾個問題來判斷一下:1)說出80386的中斷門和陷阱門的區(qū)別;2)說出保護(hù)模式與實模式的區(qū)別;3)多處理器機器上,普通的讀-改-寫回一塊內(nèi)存這樣的動作,為什么需要特殊的手段來保護(hù)。等等。講解基于其它CPU的Linux內(nèi)核的書,目前好象只有一本《IA64Linux內(nèi)核:設(shè)計與實現(xiàn)》──也還是Intel的,其它都是講解基于IA32的。以上算是知識方面吧,如果還要再補充一條,我想就是:動手編譯過內(nèi)核。好了,我們接下來走。好多人裝上Linux之后,第一件事找到內(nèi)核源碼所在的路徑,打開一個C程序文件,開始嘩嘩嘩翻頁,看看大名鼎鼎的Linux內(nèi)核代碼到底長啥模樣──然后關(guān)閉。這是可理解的,但卻不是學(xué)習(xí)的方法。剛開始,必須從讀書入手。[color=red:8c0c3b6f46]至少要對內(nèi)核有一個Overview之后,才有可能帶著問題去試圖閱讀源代碼本身。[/color:8c0c3b6f46]下面就講一下我讀過的幾本書:1,《Linux內(nèi)核設(shè)計與實現(xiàn)》,英文名LinuxKernelDevelopment(所以有人叫它LKD),機械工業(yè)出版社,¥35,美國RobertLove著,陳莉君譯者。評說:此書是當(dāng)今首屈一指的入門最佳圖書。作者是為2.6內(nèi)核加入了搶占的人,對調(diào)度部分非常精通,而調(diào)度是整個系統(tǒng)的核心,因此本書是很權(quán)威的。這本書講解淺顯易懂,全書沒有列舉一條匯編語句,但是給出了整個Linux操作系統(tǒng)2.6內(nèi)核的概觀,使你能通過閱讀迅速獲得一個overview。而且對內(nèi)核中較為混亂的部分(如下半部),它的講解是最透徹的。對沒怎么深入內(nèi)核的人來說,這是強烈推薦的一本書。翻譯:翻譯水平、負(fù)責(zé)任程度都不錯,但是印刷存在一些錯誤。買了此書的朋友可以參考我在Linux高級應(yīng)用版的《Linux內(nèi)核設(shè)計與實現(xiàn)中文版勘誤》:\
                             另外,此書2005年有了第二版,目前尚無中譯本面世。我就是對照著2nd-en勘誤1st-cn的。2,《Linux內(nèi)核源代碼情景分析》上、下。毛德操、胡希明著,浙江大學(xué)出版社,上冊¥80,下冊¥70.評說:本書是基于2.4.0內(nèi)核的,比較早,也沒聽說會出第二版。上冊講解內(nèi)存管理、中斷、異常與系統(tǒng)調(diào)用、進(jìn)程控制、文件系統(tǒng)與傳統(tǒng)UnixIPC;下冊講解socket、設(shè)備驅(qū)動、SMP和引導(dǎo)。關(guān)于這套書的評價褒貶不一,我個人認(rèn)為其深度是同類著作中最優(yōu)秀的。本書基于IntelIA32體系,由于厚度大,很多體系上的知識都捎帶講解了,所以如果你想深入了解內(nèi)核的工作機制而又不非常熟悉IntelCPU的體系構(gòu)造,本書是最合適的。缺點是:版本較老,沒有TCP/IP協(xié)議棧部分(它講的socket只是Unix域協(xié)議的),圖表太少,不適合初學(xué)者入門。還有就是對學(xué)生朋友來說,可能書價偏高,這樣的話可以考慮先買上冊,因為上冊是核心部分,下冊一大部分都在講具體PCI/ISA/USB設(shè)備的驅(qū)動。翻譯:沒什么翻譯,作者是國人,而且行文流暢。本人書桌上諸多計算機經(jīng)典圖書當(dāng)中,這套是唯一又經(jīng)典又無閱讀障礙的。www.linuxforum.net內(nèi)核版好多朋友已經(jīng)把這書讀到六七遍了,我很慚愧,上冊差不多讀熟了,下冊就SMP部分還看過──但這就花費了整整1年的時間,還有好多弄不懂的。這里順便說明另外一個研究內(nèi)核常見的誤區(qū):目標(biāo)太龐大。要知道Linux內(nèi)核(最新的2.6.13)bzip2壓縮之后37M,解壓縮之后244M,根本不是哪個人能夠吃透的。即使是內(nèi)核的核心開發(fā)團(tuán)隊中,恐怕也只LinusTorvalds、AlanCox、DavidMiller、IngoMolnar寥寥數(shù)人會有比較全面的了解,其它人都是做自己專門的部分。我自己來說,目前已經(jīng)決定放棄內(nèi)存管理的全部(slab層、LRU、rbtree等)、文件系統(tǒng)部分、外設(shè)驅(qū)動部分,暫時也沒打算弄IA32以外的其它體系的部分。3,《深入理解Linux內(nèi)核》第二版。中國電力出版社。也是陳莉君譯。此書是Linux內(nèi)核黑客在推薦圖書時的首眩評說:此書C版的converse兄送了我一本第一版,因此就沒買第二版,比較后悔。因此只就第一版說一說,第一版基于2.2,第二版2.4。我見O'Reilly官方主頁上說第三版的英文版將于2005年11月出版,也不知咱們何時才能見到。此書圖表很多,形象地給出了關(guān)鍵數(shù)據(jù)結(jié)構(gòu)的定義,與《情景分析》相比,本書內(nèi)容緊湊,不會一個問題講解動輒上百頁,有提綱挈領(lǐng)的功用,但是深度上要遜于《情景分析》。4,其它的幾本書。市面上能見到的其它的Linux內(nèi)核的圖書,象《Linux設(shè)備驅(qū)動程序》、《Linux內(nèi)核源代碼完全注釋》以及新出的《Linux內(nèi)核分析及編程》等。《Linux設(shè)備驅(qū)動程序》第二版是基于2.4的,中文翻譯不錯,中國電力出版。這書強調(diào)動手實踐,但它是講解“設(shè)備驅(qū)動”的,不是最核心的東西,而且有些東西沒硬件的話無法實踐,可能更適合驅(qū)動開發(fā)的程序員吧,不太適合那些Forfunandprofit的人。此書有第三版英文版,東南大學(xué)出版社影印,講解2.6的,行文流暢,講解的面也比第二版更廣泛,我讀過其中關(guān)于同步與互斥、內(nèi)存分配的部分,感覺很不錯。《Linux內(nèi)核源代碼完全注釋》(機械工業(yè)出版社)是同濟(jì)大學(xué)的博士生趙炯的著作,講解0.1Linux內(nèi)核,我沒買也沒看,有看過的朋友說一說。《Linux內(nèi)核分析及編程》(電子工業(yè)出版社)是剛剛出版的,國人寫的,講解2.6.11。很多人說好,但有人說不夠系統(tǒng),我沒買,不敢評說。還有一本清華出的《Linux內(nèi)核編程指南(第三版)》,原書應(yīng)該是好書,但是翻譯、排版十分糟爛,脫字跳行,根本沒法看,我買了一本又扔掉了。5,其它資源。TLDP(TheLinuxDocumentationProject)有大量文檔,其中不少是關(guān)于內(nèi)核的,有些是在國外出版過的,象《LinuxKernelInterls》《TheLinuxKernel》《LinuxKernelModuleProgrammingGuide》等,作者都是親身參加開發(fā)的人,著作較為可信。該版是研究內(nèi)核的中文Linux社區(qū)中水平最高的,有很多專家級別的牛人,強烈推薦去學(xué)習(xí)一下(但建議不要問太過分簡單的問題,人家脾氣再好也會煩的^_^),它的置頂貼簡直是一個包羅萬象的FAQ,精華區(qū)也有很多資料。只可惜太過曲高和寡,人氣不是很旺。6,一本不是講解Linux的書:《現(xiàn)代體系結(jié)構(gòu)上的Unix系統(tǒng):內(nèi)核程序員的SMP和Caching技術(shù)》,人民郵電出版社2003版,定價¥39.本書雖然不是講解Linux,但是對所有Unix內(nèi)核都是適用的,適合對SMP和CPU的Cache這些組成原理知識不是很熟的朋友,而且是很多國外牛人推薦的書。中文版翻譯非常負(fù)責(zé)。還有個很重要的問題:怎樣瀏覽內(nèi)核源代碼。有的朋友喜歡在Windows上工作,用SourceInsight;有的在Linux,用SourceNavigator;還有專門瀏覽源代碼的軟件,象lxr(LinuxCrossReference);還有用ctags/ectags/cscope等,這些都是很優(yōu)秀的軟件。我個人用Vim+ctags瀏覽(參考了www.linuxforum.net內(nèi)核版wheelz大俠的文檔,)。此外,前邊已經(jīng)提到的一個重要的問題是:你研究內(nèi)核的目的是什么,開發(fā)?樂趣?如果是開發(fā),而且是國內(nèi)做開發(fā),把kernelAPI熟悉一下就差不太多了(你也知道國內(nèi)的水平有多差),比方說copy_from_user()、kmalloc()函數(shù)等,kernelAPI在Internet上找得到,編譯內(nèi)核時也可以用DocBook生成(具體請參考內(nèi)核源代碼包下的README文件);如果是研究,那就差別很大了,需要下很大的苦功:會用kmalloc()絕不說明你懂得Linux內(nèi)核的虛存管理子系統(tǒng),正如同會講漢語不說明你懂中國文化一樣";

                
            int len = strlen(pch); 

                
            char * pDest = new char[len+1];

                
            int number = 1000000;
                printf(
            "源字符串長度:%d;運行次數(shù):%d次\n", len,number);

                DWORD take 
            = GetTickCount();   
                
            for (int i=0;i < number;++i)
                
            {
                    strcpy(pDest,pch);
                }

                printf(
            "strcpy消耗時間:%ldms\n", GetTickCount() - take);
               
                take 
            = GetTickCount();   
                
            for (int i=0;i < number;++i)
                
            {
                    memcpy(pDest,pch,strlen(pch));
                }

                printf(
            "memcpy算len消耗時間:%ldms\n", GetTickCount() - take);

                take 
            = GetTickCount();   
                
            for (int i=0;i < number;++i)
                
            {
                    memcpy(pDest,pch,len);
                }

                printf(
            "memcpy消耗時間:%ldms\n", GetTickCount() - take);

                
            while(1);
                
            return 0;
            }
             

             

             運行結(jié)果如下:

            注:我的機器是Inter Core2 4G內(nèi)存。編譯器是Visual Studio2010。

            由此可見,strcpy消耗的時間是memcpy消耗時間的24倍!

            結(jié)論:倡導(dǎo)用memcpy替代strcpy/strncpy!

            posted on 2011-04-02 12:42 Tim 閱讀(9881) 評論(11)  編輯 收藏 引用 所屬分類: C/C++語言

            評論

            # re: 用memcpy替代strcpy/strncpy 2011-04-02 14:43 Pear

            結(jié)論很可怕  回復(fù)  更多評論   

            # re: 用memcpy替代strcpy/strncpy[未登錄] 2011-04-02 15:07 Rick

            這個優(yōu)化是因為 VC10 能夠(好像從VC8 開始就可以了)識別strlen(pch) 每次是不變的,因此能優(yōu)化第二種方法。

            VC7之下第二種方法比第一方法還略慢。  回復(fù)  更多評論   

            # re: 用memcpy替代strcpy/strncpy 2011-04-02 15:58 溪流

            僅僅以快或慢來決定用哪個我覺得不好
            這兩個函數(shù)的語義是不同的,要看上下文中你要操作的究竟是字符串還是普通內(nèi)存。就算沒法區(qū)分這一點,快慢也并非唯一標(biāo)準(zhǔn),可能還有一些因素是重要的。
            (抱歉,最近有點排斥“唯性能主義”。)  回復(fù)  更多評論   

            # re: 用memcpy替代strcpy/strncpy 2011-04-02 21:08 空明流轉(zhuǎn)

            String Copy: 0.780090s
            Memory copy with String length: 1.013676s

            很顯然還是后者要慢一點。  回復(fù)  更多評論   

            # re: 用memcpy替代strcpy/strncpy 2011-04-02 21:09 空明流轉(zhuǎn)

            int str_len = 819200;
            char* old_str = new char[str_len+1];
            char* new_str = new char[str_len+1];
            for( int i = 0; i < str_len; ++i ){
            old_str[i] = 'a' + i % ('Z' - 'a');
            }
            old_str[str_len] = '\0';
            std::string strcopy( "String Copy: ");
            {
            timer t(strcopy);
            for (int i = 0; i < 1000; ++i ){
            strcpy(new_str, old_str);
            }
            }
            cout << strcopy << endl;

            std::string strlen_memcpy( "Memory copy with String length: ");
            {
            timer t(strlen_memcpy);
            for (int i = 0; i < 1000; ++i ){
            memcpy(new_str, old_str, strlen(new_str) );
            }
            }
            cout << strlen_memcpy << endl;  回復(fù)  更多評論   

            # re: 用memcpy替代strcpy/strncpy 2011-04-02 21:21 johnny chan

            不是很同意樓主的觀點,代碼的清晰性是比性能更重要,而且大多數(shù)用strcpy的情況其實用不了那么長的字符串(有其它方案解決),所以性能上的差距是可以忽略的。這也符合KISS原則的哲學(xué)。  回復(fù)  更多評論   

            # re: 用memcpy替代strcpy/strncpy 2011-04-04 10:08 ths

            我的運行結(jié)果:
            在DEV-C++中:
            strcpy消耗時間:2797ms
            memcpy算len消耗時間:2719ms
            memcpy消耗時間:562ms

            在VS2010中運行:
            strcpy消耗時間:3063ms
            memcpy算len消耗時間:2812ms
            memcpy消耗時間:610ms

            在第二項與樓主的運行結(jié)果差距較大。
              回復(fù)  更多評論   

            # re: 用memcpy替代strcpy/strncpy 2011-04-11 09:23 Tim

            的確,按照分析,應(yīng)該第二項運行時間比第三項應(yīng)該更長,似乎你的運行結(jié)果更合理。但是我在我的機器上release測試了很多次,結(jié)果都差不多是我給的圖。不過無論是你給的那個數(shù)據(jù),都至少說明了strcpy的時間比memcpy還是明顯要長的。@ths
              回復(fù)  更多評論   

            # re: 用memcpy替代strcpy/strncpy 2011-04-11 09:26 Tim

            呵呵,當(dāng)然我在文中開始就強調(diào)了兩者語義的區(qū)別。不過我這里只是從性能上給予一個小比較,我想如果可以,考慮到性能上的這一點還是有幫助的。@溪流
              回復(fù)  更多評論   

            # re: 用memcpy替代strcpy/strncpy 2011-04-11 09:28 Tim

            有道理@Rick
              回復(fù)  更多評論   

            # re: 用memcpy替代strcpy/strncpy 2011-04-11 10:19 Tim

            我沒有你用的timer類,但是我想改用GetTickCount做性能測試應(yīng)該不會比額外封裝的類有更大的誤差吧。另外,你提供的代碼中似乎存在另外一個小筆誤:
            memcpy(new_str, old_str, strlen(new_str) );在new_str未初始化時,是可能導(dǎo)致崩潰的,一并修改memcpy(new_str, old_str, strlen(old_str) );
            所以我運行的測試代碼是:
            int str_len = 819200;
            char* old_str = new char[str_len+1];
            char* new_str = new char[str_len+1];
            for( int i = 0; i < str_len; ++i ){
            old_str[i] = 'a' + i % ('Z' - 'a');
            }
            old_str[str_len] = '\0';
            DWORD take = GetTickCount();
            std::string strcopy( "String Copy: ");
            {
            //timer t(strcopy);
            take = GetTickCount();
            for (int i = 0; i < 1000; ++i )
            {
            strcpy(new_str, old_str);
            }
            }
            cout<< strcopy << GetTickCount() - take <<endl;

            std::string strlen_memcpy( "Memory copy with String length: ");
            {
            // timer t(strlen_memcpy);
            take = GetTickCount();
            for (int i = 0; i < 1000; ++i ){
            //memcpy(new_str, old_str, strlen(new_str) );
            memcpy(new_str, old_str, strlen(old_str) );
            }
            }
            cout << strlen_memcpy << GetTickCount() - take<< endl;

            在release下,運行結(jié)果是:

            String Copy: 562
            Memory copy with String length:359
            在只循環(huán)1000次的條件下,就有這種差別,性能的差別可見還是很明顯的。
            @空明流轉(zhuǎn)
              回復(fù)  更多評論   

            <2011年4月>
            272829303112
            3456789
            10111213141516
            17181920212223
            24252627282930
            1234567

            導(dǎo)航

            統(tǒng)計

            公告

            本博客原創(chuàng)文章,歡迎轉(zhuǎn)載和交流。不過請注明以下信息:
            作者:TimWu
            郵箱:timfly@yeah.net
            來源:www.shnenglu.com/Tim
            感謝您對我的支持!

            留言簿(9)

            隨筆分類(173)

            IT

            Life

            搜索

            積分與排名

            最新隨筆

            最新評論

            閱讀排行榜

            一本久久综合亚洲鲁鲁五月天亚洲欧美一区二区| 久久AV高清无码| 久久er国产精品免费观看8| 欧美激情精品久久久久久久九九九| 久久久久这里只有精品 | 蜜桃麻豆www久久国产精品| 久久99热这里只频精品6| 996久久国产精品线观看| 久久只有这精品99| 精品久久综合1区2区3区激情| 麻豆精品久久久久久久99蜜桃| 精品国产一区二区三区久久| 久久久久99精品成人片| www性久久久com| 97久久国产综合精品女不卡| 久久久精品久久久久久| 久久综合狠狠色综合伊人| 国产精品9999久久久久| 亚洲国产精品一区二区久久hs| 欧美久久天天综合香蕉伊| 久久久精品一区二区三区| 狠狠色婷婷久久一区二区三区| 久久免费视频1| 国产精品中文久久久久久久| 久久最新免费视频| 一本色综合久久| 久久99这里只有精品国产| 狠狠色丁香婷婷久久综合五月| 无码8090精品久久一区| 麻豆国内精品久久久久久| 天堂无码久久综合东京热| 久久人人爽人人爽人人片AV麻豆| 91久久精品无码一区二区毛片| 91精品国产综合久久久久久| 97久久综合精品久久久综合| 久久免费高清视频| 国产女人aaa级久久久级| 国产成人无码精品久久久免费 | 久久九九精品99国产精品| 久久无码人妻一区二区三区午夜| 久久婷婷五月综合色奶水99啪|