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

            堆和棧【翻譯】

            看到一篇比較有意思的文章,在這里就翻譯一下,當(dāng)今天發(fā)表的內(nèi)容了。

            from http://www.learncpp.com/cpp-tutorial/79-the-stack-and-the-heap/

            一個程序?qū)τ趦?nèi)存的使用,一般可以分為四類:

            1. 代碼區(qū)域,通過的編譯的程序在代碼中存儲的位置

            2. 全局變量區(qū)域,全局變量存儲的位置

            3. 堆,動態(tài)內(nèi)存分配的變量存儲的位置

            4. 棧,函數(shù)參數(shù)和局部變量存儲的位置

            下面將主要針對3,4兩個方面進(jìn)行論述。

             

            堆是一個用于動態(tài)分配的很大的內(nèi)存池。在C++中,當(dāng)你使用new操作符分配內(nèi)存時,這個內(nèi)存是從堆中取得的。

               1: int *pValue = new int; // pValue is assigned 4 bytes from the heap
               2: int *pArray = new int[10]; // pArray is assigned 40 bytes from the heap

            因為,要分配的內(nèi)存的準(zhǔn)確位置事先是不知道的,所以分配的內(nèi)存是間接獲取的,也就說明了為什么new操作符返回的是指針。這里你并不需要擔(dān)心背后內(nèi)存具體如何分配的機(jī)制。但是,有一點(diǎn)值得明了,連續(xù)的內(nèi)存請求所指向的很可能不是連續(xù)的地址的內(nèi)存片段。如:

               1: int *pValue1 = new int;
               2: int *pValue2 = new int;
               3: // pValue1 and pValue2 may not have sequential addresses

            上例中,兩個new是連續(xù)的,但是分配得到的pValue1和pValue2的地址是不連續(xù)的。當(dāng)動態(tài)分配的變量被刪除后,內(nèi)存有被返回到堆中以備后續(xù)中再次被動態(tài)分配。

            堆有如下優(yōu)缺點(diǎn):

            1. 分配的內(nèi)存一直處于被分配的狀態(tài),知道去分配操作出現(xiàn),才回到初始狀態(tài)(沒有及時去分配,如new后沒有用delete,會導(dǎo)致內(nèi)存的泄漏)。

            2. 動態(tài)分配的內(nèi)存必須通過指針聯(lián)系

            3. 由于堆是一個很大的內(nèi)存池,大的數(shù)組,結(jié)構(gòu),類都應(yīng)該在這里分配得到內(nèi)存

             

            棧調(diào)用扮演了一個很有趣的角色。在我們討論棧調(diào)用之前,讓我們討論一下什么叫做棧。

            想象一下自助餐廳中的一堆疊起來的盤子。因為每個盤子都比較重,它們被疊起來的,你只能做以下三件事情。

            1)看向最上面的盤子

            2)將最上面的盤子拿掉

            3)在上面放一個新的盤子

            在計算機(jī)編程中,棧是一個存儲其他變量的容器(很像一個數(shù)組)。但是,一個數(shù)組能夠以你想要的方式任意更改獲取其中的元素,棧則有更多的限制,棧中能夠進(jìn)行的操作如下:

            1)查看棧頂?shù)捻?/p>

            2)將棧頂?shù)捻棌捻敳恳瞥?/p>

            3)將一個新的項放置頂部

            棧是后進(jìn)先出(LIFO)的數(shù)據(jù)結(jié)構(gòu)。

            (略掉一些內(nèi)容······)

            我們主要來看當(dāng)調(diào)用函數(shù)是棧發(fā)生了一些什么行為。

            1)發(fā)生函數(shù)調(diào)用處的相關(guān)指令的地址被push進(jìn)棧中

            2)函數(shù)返回類型置于棧中,設(shè)置一個占位符

            3)CPU跳至函數(shù)的代碼中

            4)現(xiàn)在棧頂?shù)膬?nèi)容是一個特殊指針,棧幀。隨后所有的加入到棧中的內(nèi)容都是該函數(shù)的局部信息。

            5)所有的函數(shù)參數(shù)都被放入棧中

            6)函數(shù)中的指令得到執(zhí)行

            7)函數(shù)中的局部變量push棧中

            當(dāng)函數(shù)結(jié)束的時候,發(fā)生如下事件:

            1)函數(shù)的返回值拷貝進(jìn)入一個占位符中,

            2)在棧幀之后的所有內(nèi)容都被pop off,所有的局部變量都被銷毀

            3)返回值被pop off并賦值給函數(shù)中的變量,如果調(diào)用函數(shù)的返回值沒有賦值給任何東西,該值就會丟失

            4)下一個語句的地址從棧中pop off,CPU繼續(xù)執(zhí)行

             

            棧溢出

            棧的大小是有限的,只能有序的容納一定量的信息。如果程序試圖向棧中放入過多的信息,棧將會溢出。棧溢出發(fā)生在棧的內(nèi)存都被分配完了,那種情況下,更多的分配,將會發(fā)生在內(nèi)存的其它片段中。

            棧溢出通常發(fā)生在分配了太多的變量到棧上,或太多的嵌套函數(shù)調(diào)用,導(dǎo)致結(jié)果就是程序的奔潰。

            如:

               1: int main()
               2: {
               3:     int nStack[100000000];
               4:     return 0;
               5: }

            棧的優(yōu)缺點(diǎn):

            * 棧中的內(nèi)容可以一直保留到pop off發(fā)生

            * 編譯時,棧中分配的內(nèi)存是已知的,因此,可以直接通過變量訪問內(nèi)存。

            * 因為棧相對而言是比較小的,所以小心會吃掉很多棧空間的事情。包括大型數(shù)組,結(jié)構(gòu)體,類過多的內(nèi)嵌,過多的遞歸等。

            posted on 2012-05-27 23:08 鐘謝偉 閱讀(1853) 評論(3)  編輯 收藏 引用

            評論

            # re: 堆和棧【翻譯】 2012-05-28 08:40 tb

            一直認(rèn)為是進(jìn)和出的關(guān)系   回復(fù)  更多評論   

            # re: 堆和棧【翻譯】 2012-06-17 23:31 nonoob

            在函數(shù)調(diào)用時設(shè)置的占位符是返回值類型的指針還是返回值本身?  回復(fù)  更多評論   

            # re: 堆和棧【翻譯】 2012-06-18 17:36 鐘謝偉

            @nonoob
            我覺得,可能是在內(nèi)存中預(yù)留出1個具有返回值大小的空間,然后在棧中保留該空間的地址??----猜測,不知道怎么跟蹤代碼查看詳情,額  回復(fù)  更多評論   


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


            <2012年7月>
            24252627282930
            1234567
            891011121314
            15161718192021
            22232425262728
            2930311234

            導(dǎo)航

            統(tǒng)計

            常用鏈接

            留言簿(1)

            隨筆檔案

            IT網(wǎng)站

            My Friends

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            狠狠色伊人久久精品综合网 | 亚洲国产成人精品久久久国产成人一区二区三区综 | 青春久久| 午夜天堂av天堂久久久| 蜜桃麻豆www久久| 色偷偷91久久综合噜噜噜噜| 亚洲AV日韩AV天堂久久| 青青草原1769久久免费播放| 亚洲精品视频久久久| 国产69精品久久久久777| 久久夜色精品国产亚洲av| 蜜臀av性久久久久蜜臀aⅴ| 精品久久久久久国产三级| 蜜臀av性久久久久蜜臀aⅴ| 久久91这里精品国产2020| 久久99精品久久只有精品| 国产精品99久久久精品无码| 国产2021久久精品| 99久久无色码中文字幕| 中文字幕乱码久久午夜| 久久午夜福利电影| 国产亚洲精久久久久久无码AV| 国产精品久久久久国产A级| 久久精品无码一区二区WWW| 精品久久久久久国产牛牛app| 久久久青草久久久青草| 精品一区二区久久久久久久网站| 欧美亚洲国产精品久久高清 | 久久精品夜夜夜夜夜久久| 亚洲精品久久久www| 亚洲欧洲中文日韩久久AV乱码| 精品久久久久久国产三级| 色成年激情久久综合| 久久国产高清一区二区三区| 狠狠人妻久久久久久综合蜜桃| 国产精品成人99久久久久| 久久久国产精品福利免费| 国产精品青草久久久久福利99| 国产综合精品久久亚洲| 日本精品一区二区久久久| 国产欧美久久久精品影院|