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

            聲明順序,靜態作用域,動態作用域

            為了說明c++的聲明順序所導致的作用域問題,考慮如下代碼
             1 #include<iostream>
             2 //#include <map>
             3 //#include <string>
             4 using namespace std;
             5 
             6 int a;
             7 void first()
             8 {
             9     a = 1;
            10 }
            11 
            12 void second()
            13 {
            14     int a = 7;
            15     first();
            16     cout << "second:" << a << endl;
            17 }
            18 
            19 
            20 int main()
            21 {
            22     a = 2;
            23     int num;
            24     cin >> num;
            25     if (num > 0)
            26     {
            27         second();
            28     }
            29     else
            30     {
            31         first();
            32     }
            33     cout << a << endl;
            34     return 0;
            35 }
            36 
            猜想一下上面的代碼輸出的結果是什么?main函數中輸出的結果是1。不論你輸入的num值是正數還是負數結果都是1。為什么會這樣呢?這是因為c++采用的是靜態作用域規則。第9行代碼是關鍵所在。對于c++這種靜態語言而言,第9行代碼實際修改的是全局變量a的值。所以該程序的最終結果會是1。那么動態作用域規則的語言會輸出什么樣的結果呢?那就要根據所輸入的num來決定了。

            c++聲明變量的作用就是引進名字符號,表明該變量的作用域,而定義則是給變量分配內存,并且綁定值的過程。對于調用子函數的過程,為了找到子函數中的變量的聲明作用域,編譯器采用了靜態鏈接的方法。對于程序的執行流程,編譯器會維護一個棧,棧中會存儲與相應調用函數對應的幀。編譯器通過棧和幀數據結構來維護程序執行所調用的函數層次流程。要找到一個子函數中的變量聲明域實際上就是在棧中相應幀中尋找該變量的聲明。尋找起點是當前活動幀,而當前活動幀又通過靜態鏈接(相當于指針)與它的父幀相關聯。但是考慮上面的程序,當輸入num大于0時,應該是先調用second,然后調用first,而second中對變量a重新進行了聲明,如果棧中維護的層次是函數調用的層次,則此時first中修改的變量a應該是second中聲明的變量a才是,那么結果輸出應該是2,但是事實并非如此。所以我認為棧中的靜態鏈接所鏈接的不是函數調用的層次,而是聲明的層次。考慮上面的程序,全局變量a和函數first的聲明是在同一層次的,則如果要尋找a中變量的聲明,應該首先查找a所在的那個模塊所對應的幀(姑且認為是全局幀吧,看成有一個全局范圍的函數與之對應),則這時找到的a的聲明應該就是全局變量a。所以如果按照這種分析的話,那么程序的結果就是1了。

            以上只是我的猜想,由于最近要忙于考試,沒有時間查閱更多資料,且編譯原理那塊已經幾乎忘得差不多了。如有錯誤請各位指正。


            posted on 2011-06-18 17:37 MrRightLeft 閱讀(750) 評論(0)  編輯 收藏 引用 所屬分類: C/C++

            <2011年6月>
            2930311234
            567891011
            12131415161718
            19202122232425
            262728293012
            3456789

            導航

            統計

            隨筆分類

            隨筆檔案

            文章分類

            文章檔案

            搜索

            最新評論

            閱讀排行榜

            評論排行榜

            久久男人AV资源网站| 国产偷久久久精品专区| 狠狠色丁香久久婷婷综合五月| 久久精品中文騷妇女内射| 久久综合狠狠色综合伊人| 久久综合亚洲色HEZYO国产| 亚洲精品无码久久久久| 国产精品九九久久免费视频 | 性做久久久久久久久老女人| 2021国内久久精品| 久久最新精品国产| 久久强奷乱码老熟女网站| 国产精品毛片久久久久久久| 香蕉aa三级久久毛片| 久久综合丝袜日本网| 久久www免费人成看片| 国产高清美女一级a毛片久久w| 久久精品国产亚洲av麻豆蜜芽| 免费国产99久久久香蕉| 国产激情久久久久久熟女老人| 亚洲伊人久久大香线蕉苏妲己| 亚洲欧美成人综合久久久| 久久这里有精品| 久久国产午夜精品一区二区三区| 亚洲国产精品18久久久久久| 亚洲国产日韩欧美综合久久| 国产精品免费久久久久影院| 久久国产精品国产自线拍免费| 99精品久久精品一区二区| 亚洲精品视频久久久| 久久精品国产亚洲AV不卡| 国产午夜久久影院| 久久国产精品-久久精品| 久久亚洲精品人成综合网| 国内高清久久久久久| 亚洲第一极品精品无码久久| 日韩精品久久久久久久电影蜜臀 | 丁香色欲久久久久久综合网| 天天综合久久一二三区| 区亚洲欧美一级久久精品亚洲精品成人网久久久久 | 亚洲а∨天堂久久精品|