• <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++博客 首頁 新隨筆 聯系 聚合 管理
              118 Posts :: 3 Stories :: 413 Comments :: 0 Trackbacks
            在進行靜態強類型語言的設計過程中,是一定需要提供一種語法實現變量和類型的關聯。這種語法一般稱之為 “聲明” 或者 “定義”。

            如果用一種人類易讀的方式進行表達,可以寫作 define variable_name as type_name。沒有錯,你看到的這種形式類似于VB當中 Dim As的方法。在語法分析的過程中,這種方法的好處很明顯。define 作為提示字,意味著一個聲明或者定義的開始,as 則代表后續的Tokens都是用于一個類型的,這樣關鍵字可以很顯著的將語義區分開。

            但是這種寫法并不方便。C 一類的語言,都選用一種 prefix declaration specifier 的方式,也就是我們常常見到的:type_name variable_name 這樣的形式。舉個最簡單的例子,int i;。如果有類型修飾,可以作為一個基本類型的前綴或者后綴出現。例如const int i; 或者 int const i; 至于修飾含義是左綁定還是右綁定,這個需要取決于語言本身的設計。

            如果事情是這個樣子的話,也就沒什么好說的了。但是在C語言里面,有兩個例外:函數和數組。例如,在C里面定義一個數組,寫作:const int array[expr]; 這種寫法既不是前綴寫法,也不是后綴寫法。類型被變量兩分了。如果僅僅是一個數組定義,那也好辦,當做特殊情況處理就好了。
            但是有時候我們的數組元素會變得非常復雜。 舉個例子,( struct {...} const [ constant ] identifier ( params... )  ) [ expr ]。你能理解這樣一個復雜的定義其實是一個函數的數組么?不僅僅是你不能,我想在撰寫語法規則的時候,又困難,又不合邏輯。

            在C的EBNF中,這個問題解決起來也很復雜。
            在這里,我們簡化一下C的語法,不考慮C的指針,不考慮變量初始化,不考慮類型修飾符,也不考慮一個類型定義多個變量的情況。
            這就意味著你只能寫 int i; int j; j = 0; 而不能寫 int i, j = 0;

            declaration ::= declaration_specifier declarator

            declarator ::= identifier
                           | delcarator '['  expr ']'
                           | declarator '(' parameters_declaration_list ')'
                           | '(' declarator ')'


            那么我問你,declarator是個什么東西。變量名?不是。函數聲明?也不是。數組?也不是。declaration_specifier呢?變量類型?是。數組元素類型?是。函數返回值類型?也是。顯然這樣一個語法要素具備了太多的語義。更重要的是,沒到最后,你是沒法確定declaration_specifier究竟是一個什么含義,identifier所代表的,究竟是個什么東西。顯然只有在聲明匹配完成之后,還需要進行復雜的推導過程,才能確定變量的嵌套結構。

            這個問題還導致了C語言里面的這么一個特性:那就是很出名的指針符號*的變量綁定性質。在C語言中,*,[],() 操作符并沒有理解為對類型的修飾,而是理解為對變量的修飾。這就讓我們必須要這么寫: int m[expr], n[expr]; int m( int, int ), n( int, float );
            而對變量,寫法就成了: int x, y; 這導致了同樣的寫法兩者在語義上的不一致性。這也是為什么新手云里霧里的根本原因了。按照普通變量的規矩,函數應該寫成 int (x, y) (int);這樣的結構。好吧,這樣還挑戰不倒你。但是如果我更復雜一點,加上初始化呢?就變成了 int ( x = p0, y ) (int) 這樣的結構,呃。

            為什么C會這么做?難道完全的前置類型會讓語法分析工作變難么?很顯然不會。雖然C語言如此聲明的出發點不可考,但是想讓普通類型和數組聲明維持同樣的語法結構是很簡單的事情,C#就給了一個很好的答案。在C#中,變量是如此聲明的:

            declaration ::= declaration_specifier declarator
            declaration_specifier ::= function_specifier | array_specifier | identifier
                                      | '(' declaration_specifier ')'
            function_specifier ::= declaration_specifier '(' parameter_declaration_list ')'
            array_specifier ::= declaration_specifier '[' expression_list ']'


            這樣,declaration_specifier完全就變成了類型,而declarator部分就和類型脫鉤了。在這種聲明方式中,我們就這么定義一個變量 int [] x, y, z; OK,這樣大家就理解了,x,y,z都是一個數組。而不會造成C語言當中的誤解。

            最后討論一下類型修飾的問題。這里只討論單一類型的類型修飾,下面我們會看到,復合類型其實也是一樣的。我們將類型聲明和表達式進行類比,就可以將類型理解為變量,類型修飾理解為單目操作符。

            const type  <==類比==>  ~var

            const就相當于按位取反操作符~,type就相當于var。const type這個表達式的結果就是一個常量化的type。那么,我們可以更廣泛的將聲明理解成 type_expression variable_name 這樣的形式。type_expression在語義分析的時候進行類型演算得出結果,variable_name則利用類型表達式獲得真正的類型,并實例化。下面我們寫出type_expression的演算語法:

            type_expression ::= type_identifier
                                | type_op type_expression  /* prefix  style */
                                | type_expression type_op  /* postfix style */
            type_op ::= type_qualifier

            當然,對于 const int volatile 這樣的聲明,這個表達式還有二義性。這個二義性可以通過一定的方法消除,這一點一般的編譯原理教材都有詳細的討論。并且,我們完全可以將()和[]也納入到type_operator中,這兩個操作一個可以構造出函數類型,一個構造出數組類型來,這樣類型問題就得到了一個遞歸一致的解決。

            當然,更重要的是,我將type_expression variable_name這樣的聲明式變成typedef type_expression variable_name呢?

            哈哈。

            最后嚴重感謝一下VCZH,因為這小子吃了足夠的shit,我就可以不用繼續吃shit了。正所謂前人栽樹后人乘涼。

            posted on 2009-02-25 01:33 空明流轉 閱讀(1973) 評論(2)  編輯 收藏 引用

            評論

            # re: 靜態強類型語言的類型聲明與變量聲明 2009-02-25 01:43 陳梓瀚(vczh)
            囧  回復  更多評論
              

            # re: 靜態強類型語言的類型聲明與變量聲明[未登錄] 2009-02-27 09:37 六水
            哈哈,這句說的太經典了  回復  更多評論
              

            精品熟女少妇a∨免费久久| 国产高潮国产高潮久久久91| 狠色狠色狠狠色综合久久| A级毛片无码久久精品免费| 久久精品一区二区影院| 精品综合久久久久久88小说| 亚洲综合久久综合激情久久 | 久久精品国产99久久香蕉| av午夜福利一片免费看久久| 亚洲精品无码久久久久去q | AV无码久久久久不卡网站下载 | 久久精品嫩草影院| 久久最近最新中文字幕大全 | 91秦先生久久久久久久| 国产成人精品久久一区二区三区av| 欧美日韩中文字幕久久伊人| 91久久国产视频| 四虎亚洲国产成人久久精品| 人妻少妇精品久久| 午夜精品久久久久久影视777| 亚洲午夜精品久久久久久浪潮| 久久强奷乱码老熟女网站| 久久综合国产乱子伦精品免费| 久久精品国产清高在天天线| 中文字幕亚洲综合久久2| 久久久久久极精品久久久| 亚洲国产日韩欧美久久| 久久精品国产亚洲AV麻豆网站| 一本一道久久精品综合| 亚洲精品国精品久久99热| 亚洲av伊人久久综合密臀性色| 免费精品99久久国产综合精品| 无码乱码观看精品久久| 日本强好片久久久久久AAA| 国产精品欧美久久久久天天影视| 久久午夜福利无码1000合集| 久久ZYZ资源站无码中文动漫| 久久久久久极精品久久久| 久久人人爽人人爽人人AV| 久久久久人妻精品一区三寸蜜桃| 人妻无码中文久久久久专区|