青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

無我

讓內心永遠燃燒著偉大的光明的精神之火!
靈活的思考,嚴謹的實現
豪邁的氣魄、頑強的意志和周全的思考

用memcpy替代strcpy/strncpy

      首先描述一下三個相關函數strcpy/strncpy、memcpy和memmove的意義。

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

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

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

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

 

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

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

    
int len = strlen(pch); 

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

    
int number = 1000000;
    printf(
"源字符串長度:%d;運行次數:%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;
}
 

 

 運行結果如下:

注:我的機器是Inter Core2 4G內存。編譯器是Visual Studio2010。

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

結論:倡導用memcpy替代strcpy/strncpy!

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

評論

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

結論很可怕  回復  更多評論   

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

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

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

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

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

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

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

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

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

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;  回復  更多評論   

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

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

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

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

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

在第二項與樓主的運行結果差距較大。
  回復  更多評論   

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

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

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

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

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

有道理@Rick
  回復  更多評論   

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

我沒有你用的timer類,但是我想改用GetTickCount做性能測試應該不會比額外封裝的類有更大的誤差吧。另外,你提供的代碼中似乎存在另外一個小筆誤:
memcpy(new_str, old_str, strlen(new_str) );在new_str未初始化時,是可能導致崩潰的,一并修改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下,運行結果是:

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

<2013年7月>
30123456
78910111213
14151617181920
21222324252627
28293031123
45678910

導航

統計

公告

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

留言簿(9)

隨筆分類(173)

IT

Life

搜索

積分與排名

最新隨筆

最新評論

閱讀排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            夜久久久久久| 亚洲一区二区av电影| 久久青青草综合| 久久青青草原一区二区| 免费不卡亚洲欧美| 欧美精品aa| 国产精品―色哟哟| 国内精品久久久| 一区二区三区自拍| 亚洲激情偷拍| 一区二区三区不卡视频在线观看 | 国产精品99久久久久久有的能看| 夜夜嗨av色综合久久久综合网| 亚洲在线1234| 美女久久一区| 亚洲精品国精品久久99热一| 亚洲视频播放| 久久手机精品视频| 欧美午夜欧美| 亚洲国产精品久久久久| 亚洲欧美日韩一区在线观看| 免费短视频成人日韩| 99精品久久| 久久久夜色精品亚洲| 欧美午夜影院| 亚洲黄色性网站| 午夜精品剧场| 亚洲欧美日韩在线观看a三区| 欧美一区二区三区喷汁尤物| 男男成人高潮片免费网站| 欧美成人午夜激情视频| 亚洲精品视频免费| 欧美一区二视频在线免费观看| 久久久之久亚州精品露出| 亚洲激情视频网| 欧美亚洲视频在线看网址| 欧美日韩久久精品| 亚洲国产精品va在线观看黑人| 亚洲欧美国产精品桃花| 亚洲高清在线观看| 欧美中文字幕视频| 国产精品久久婷婷六月丁香| 亚洲日韩欧美一区二区在线| 久久国产精品一区二区三区四区| 夜夜狂射影院欧美极品| 欧美福利在线| 亚洲丰满少妇videoshd| 久久久久久久网| 欧美亚洲免费在线| 国产精品一区视频网站| 亚洲在线国产日韩欧美| 亚洲美女毛片| 欧美色区777第一页| 在线一区二区三区四区| 日韩手机在线导航| 欧美视频专区一二在线观看| 一区二区欧美日韩视频| 日韩午夜中文字幕| 欧美日韩另类在线| 亚洲午夜久久久| 妖精成人www高清在线观看| 欧美日韩美女一区二区| 亚洲视频第一页| 亚洲一二三区视频在线观看| 国产精品女人久久久久久| 欧美一区二区黄色| 欧美一区二区女人| 黄色一区二区在线| 欧美大片免费观看| 欧美激情免费在线| 亚洲在线观看视频| 午夜激情综合网| 伊人狠狠色j香婷婷综合| 欧美成人国产一区二区| 欧美精品一区二区三区久久久竹菊| 99精品免费视频| 亚洲一级免费视频| 黄色免费成人| 亚洲高清不卡在线观看| 欧美视频日韩视频在线观看| 欧美一区二粉嫩精品国产一线天| 欧美在线观看你懂的| 在线视频国产日韩| 中国女人久久久| 伊人色综合久久天天五月婷| 亚洲国产一区视频| 国产欧美一区二区精品忘忧草 | 亚洲另类春色国产| 亚洲精品一区二区三| 国内揄拍国内精品少妇国语| 欧美在线中文字幕| 在线欧美福利| 99国产精品视频免费观看一公开| 国产精品免费看片| 免费在线观看一区二区| 欧美视频一区在线| 久久综合精品国产一区二区三区| 欧美精品九九| 麻豆av福利av久久av| 国产精品久久久久久妇女6080 | 欧美~级网站不卡| 欧美日韩一区二区精品| 久久婷婷影院| 欧美日韩国产黄| 久久久精品国产免大香伊| 欧美日韩大片一区二区三区| 久久久久一区| 国产精品久久国产三级国电话系列 | 久久久www免费人成黑人精品| 日韩一级大片在线| 久久精品日产第一区二区| 日韩一级免费观看| 久久九九热re6这里有精品| 亚洲一区二区免费| 欧美成人精品在线| 蜜桃久久精品一区二区| 国产日韩成人精品| 亚洲综合不卡| 亚洲视频欧洲视频| 欧美精品黄色| 最新国产成人av网站网址麻豆| 狠狠入ady亚洲精品| 亚洲欧美日本在线| 亚洲在线第一页| 欧美日韩综合视频网址| 亚洲激情二区| 亚洲精品综合精品自拍| 久久这里有精品视频| 六月天综合网| 亚洲成人在线| 毛片av中文字幕一区二区| 久久一区二区三区av| 国内成人精品视频| 欧美在线不卡| 猛男gaygay欧美视频| 韩国女主播一区| 久久久蜜桃一区二区人| 毛片一区二区| 亚洲第一在线视频| 欧美11—12娇小xxxx| 亚洲第一伊人| 一本到高清视频免费精品| 欧美全黄视频| 亚洲香蕉伊综合在人在线视看| 亚洲专区一区二区三区| 国产精品视频免费观看| 午夜在线播放视频欧美| 久久在线播放| 亚洲欧洲视频| 国产精品chinese| 亚洲精品国产精品国自产观看| 欧美另类专区| 免费久久99精品国产自| 狠狠色丁香久久综合频道| 久久xxxx| 欧美高清视频| 亚洲狼人综合| 国产精品九九| 久久国产成人| 亚洲国内在线| 亚洲男人av电影| 红桃视频亚洲| 欧美精品一区在线| 亚洲一区二区三区四区中文| 久久er精品视频| 亚洲人体影院| 国产精品久久久免费| 久久国产精品久久久久久| 亚洲第一天堂av| 午夜精品999| 在线观看国产一区二区| 欧美精品三级在线观看| 亚洲一区在线直播| 欧美超级免费视 在线| 亚洲视频二区| 在线日本欧美| 国产欧美日韩一区二区三区在线观看| 久久久亚洲人| 亚洲婷婷在线| 亚洲第一视频| 久久精品综合网| 一区二区三区久久精品| 韩国欧美国产1区| 国产精品乱码一区二区三区| 久久噜噜亚洲综合| 亚洲欧美国产视频| 亚洲精品久久久久久下一站| 久久国产黑丝| 亚洲一区影音先锋| 亚洲第一精品夜夜躁人人躁| 国产精品久久国产精品99gif| 噜噜爱69成人精品| 午夜久久黄色| 日韩网站在线观看| 猛干欧美女孩| 久久九九久精品国产免费直播| 一区二区三区欧美| 亚洲国产欧美不卡在线观看| 国产一区二区三区av电影| 久久免费精品视频|