多重定義的入口編譯原理

A. 編譯原理-LL1文法詳細講解

我們知道2型文法( CFG )，它的每個產生式類型都是 α→β ,其中 α ∈ VN , β ∈ (VN∪VT)*。

例如, 一個表達式的文法:

最終推導出 id + (id + id) 的句子，那麼它的推導過程就會構成一顆樹，即 CFG 分析樹：

從分析樹可以看出，我們從文法開始符號起，不斷地利用產生式的右部替換產生式左部的非終結符，最終推導出我們想要的句子。這種方式我們稱為自頂向下分析法。

從文法開始符號起，不斷用非終結符的候選式(即產生式)替換當前句型中的非終結符，最終得到相應的句子。
在每一步推導過程中，我們需要做兩個選擇:

因為一個句型中，可能存在多個非終結符，我們就不確定選擇那一個非終結符進行替換。
對於這種情況，我們就需要做強制規定，每次都選擇句型中第一個非終結符進行替換(或者每次都選擇句型中最後一個非終結符進行替換)。

自頂向下的語法分析採用最左推導方式，即總是選擇每個句型的最左非終結符進行替換。

最終的結果是要推導出一個特定句子(例如 id + (id + id) )。
我們將特定句子看成一個輸入字元串，而每一個非終結符對應一個處理方法，這個處理方法用來匹配輸入字元串的部分，演算法如下:

方法解析:

這種方式稱為遞歸下降分析( Recursive-Descent Parsing )：

當選擇的候選式不正確，就需要回溯( backtracking )，重新選擇候選式，進行下一次嘗試匹配。因為要不斷的回溯，導致分析效率比較低。

這種方式叫做預測分析( Predictive Parsing )：

要實現預測分析，我們必須保證從文法開始符號起，每一個推導過程中，當前句型最左非終結符 A 對於當前輸入字元 a ,只能得到唯一的 A 候選式。

根據上面的解決方法，我們首先想到，如果非終結符 A 的候選式只有一個以終結符 a 開頭候選式不就行了么。
進而我們可以得出，如果一個非終結符 A ，它的候選式都是以終結符開頭，並且這些終結符都各不相同，那麼本身就符合預測分析了。

這就是S_文法，滿足下面兩個條件:

例子:

這就是一個典型的S_文法，它的每一個非終結符遇到任一終結符得到候選式是確定的。如 S -> aA | bAB , 只有遇到終結符 a 和 b 的時候，才能返回 S 的候選式，遇到其他終結符時，直接報錯，匹配不成功。

雖然S_文法可以實現預測分析，但是從它的定義上看，S_文法不支持空產生式(ε產生式)，極大地限制了它的應用。

什麼是空產生式(ε產生式)？

例子

這里 A 有了空產生式，那麼 S 的產生式組 S -> aA | bAB ，就可以是 a | bB ,這樣 a , bb , bc 就變成這個文法 G 的新句子了。

根據預測分析的定義，非終結符對於任一終結符得到的產生式是確定的，要麼能獲取唯一的產生式，要麼不匹配直接報錯。

那麼空產生式何時被選擇呢？

由此可以引入非終結符 A 的後繼符號集的概念:
定義: 由文法 G 推導出來的所有句型，可以出現在非終結符 A 後邊的終結符 a 的集合，就是這個非終結符 A 的後繼符號集，記為 FOLLOW(A) 。

因此對於 A -> ε 空產生式，只要遇到非終結符 A 的後繼符號集中的字元，可以選擇這個空產生式。
那麼對於 A -> a 這樣的產生式，只要遇到終結符 a 就可以選擇了。

由此我們引入的產生式可選集概念:
定義: 在進行推導時，選用非終結符 A 一個產生式 A→β 對應的輸入符號的集合，記為 SELECT(A→β)

因為預測分析要求非終結符 A 對於輸入字元 a ,只能得到唯一的 A 候選式。
那麼對於一個文法 G 的所有產生式組，要求有相同左部的產生式，它們的可選集不相交。

在 S_文法基礎上，我們允許有空產生式，但是要做限制:

將上面例子中的文法改造:

但是q_文法的產生式不能是非終結符打頭，這就限制了其應用，因此引入LL(1)文法。

LL(1)文法允許產生式的右部首字元是非終結符，那麼怎麼得到這個產生式可選集。
我們知道對於產生式:

定義: 給定一個文法符號串 α ， α 的 串首終結符集 FIRST(α) 被定義為可以從 α 推導出的所有串首終結符構成的集合。

定義已經了解清楚了，那麼該如何求呢？
例如一個文法符號串 BCDe , 其中 B C D 都是非終結符， e 是終結符。

因此對於一個文法符號串 X1X2 … Xn ，求解 串首終結符集 FIRST(X1X2 … Xn) 演算法:

但是這里有一個關鍵點，如何求非終結符的串首終結符集？

因此對於一個非終結符 A , 求解 串首終結符集 FIRST(A) 演算法:

這里大家可能有個疑惑，怎麼能將 FIRST(Bβ) 添加到 FIRST(A) 中，如果問文法符號串 Bβ 中包含非終結符 A ，就產生了循環調用的情況，該怎麼辦?

對於 串首終結符集 ，我想大家疑惑的點就是，串首終結符集到底是針對 文法符號串 的，還是針對 非終結符 的，這個容易弄混。
其實我們應該知道， 非終結符 本身就屬於一個特殊的 文法符號串 。
而求解 文法符號串 的串首終結符集，其實就是要知道文法符號串中每個字元的串首終結符集:

上面章節我們知道了，對於非終結符 A 的 後繼符號集 :
就是由文法 G 推導出來的所有句型，可以出現在非終結符 A 後邊的終結符的集合，記為 FOLLOW(A) 。

仔細想一下，什麼樣的終結符可以出現在非終結符 A 後面，應該是在產生式中就位於 A 後面的終結符。例如 S -> Aa ，那麼終結符 a 肯定屬於 FOLLOW(A) 。

因此求非終結符 A 的 後繼符號集 演算法：

如果非終結符 A 是產生式結尾，那麼說明這個產生式左部非終結符後面能出現的終結符，也都可以出現在非終結符 A 後面。

我們可以求出 LL(1) 文法中每個產生式可選集:

根據產生式可選集，我們可以構建一個預測分析表，表中的每一行都是一個非終結符，表中的每一列都是一個終結符，包括結束符號 $ ，而表中的值就是產生式。
這樣進行語法推導的時候，非終結符遇到當前輸入字元，就可以從預測分析表中獲取對應的產生式了。

有了預測分析表，我們就可以進行預測分析了，具體流程:

可以這么理解：

我們知道要實現預測分析，要求相同左部的產生式，它們的可選集是不相交。
但是有的文法結構不符合這個要求，要進行改造。

如果相同左部的多個產生式有共同前綴，那麼它們的可選集必然相交。
例如:

那麼如何進行改造呢？
其實很簡單，進行如下轉換:

如此文法的相同左部的產生式，它們的可選集是不相交，符合現預測分析。

這種改造方法稱為 提取公因子演算法 。

當我們自頂向下的語法分析時，就需要採用最左推導方式。
而這個時候，如果產生式左部和產生式右部首字元一樣(即A→Aα)，那麼推導就可能陷入無限循環。
例如:

因此對於:

文法中不能包含這兩種形式，不然最左推導就沒辦法進行。

例如:

它能夠推導出如下:

你會驚奇的發現，它能推導出 b 和 (a)* (即由 0 個 a 或者無數個 a 生成的文法符號串)。其實就可以改造成:

因此消除 直接左遞歸 演算法的一般形式：

例如:

消除間接左遞歸的方法就是直接帶入消除，即

消除間接左遞歸演算法：

這個演算法看起來描述很多，其實理解起來很簡單：

思考 : 我們通過 Ai -> Ajβ 來判斷是不是間接左遞歸，那如果有產生式 Ai -> BAjβ 且 B -> ε ,那麼它是不是間接左遞歸呢？
間接地我們可以推出如果一個產生式 Ai -> αAjβ 且 FIRST(α) 包括空串ε，那麼這個產生式是不是間接左遞歸。

B. C++中兩個文件讀取一個.h時多個多重定義錯誤

從昨晚到現在查了很多東西，但結果卻超級簡單：
首先#include在編譯時會被預處理器將.h中的所有內容拷貝到當前文件中， 如果.h中還include了別的.h， 則遞歸拷貝；
如果.h文件中沒有頭文件保護，即#ifndef ... #define ... #endif則如果某文件include 1.h和 3.h, 而1.h也#include了3.h， 則會有完全相同的兩份3.h中的代碼， 這樣就直接報錯了； 但加入了頭文件保護後就可以保證在單一文件中只會編譯一遍3.h的代碼；
所以到目前為止如果加入了頭文件保護，在單一文件中不會有重聲明(定義)，編譯可以通過，生成各個.o文件了， 頭文件中定義的變數都定義並分配了空間，就你的問題而言，tool.o中有Map， 同時main.o中也有Map；
然後就是鏈接了，此時會將各.o中的全局符號加入全局符號表中，如果.o中有相同的全局變數則會報重定義， 即tool.o和main.o中的Map沖突了。

總結下：頭文件保護只是保證在 單一文件中不會重復include， 但不保證在不同文件中重復include。

解決辦法為在.h中只聲明變數： extern map Map； 而在tool.cpp中定義： map Map;

多謝問題哈，終於搞清楚了這個問題！

C. 編譯C程序出現多重定義，怎麼解決

應該是你在2個c文件中都定義了全局的MmiUtil_WaitKeyMenu，可以聲明為static，或者改個名字

D. 編譯原理筆記17：自下而上語法分析（4）LR(0)、SLR(1) 分析表的構造

（移進項目就是指圓點右邊是終結符的項目，規約項目指的就是圓點在右部最右端的項目）

LR(0) 文法可以直接通過識別活前綴的 DFA 來構造 LR 分析表

假定 C = {I ₀ , I ₁ , ... , I _n } （aka. LR(0) 項目規范族、DFA 狀態集）

首先為文法產生式進行編號，拓廣文法的產生式要標記為 0（這里就是後面分析表中 rj 的產生式編號 j 的由來）

然後令每個項目集 I _k 的下標 k 作為分析器的狀態（行首），包含 S' → .S 的集合下標為分析器的初態（也就是 DFA 的初態，一般都是 0 ）。

下面用一個例子來說明 ACTION、GOTO 子表的構造：

SLR(1) 為解決沖突提出了一個簡單的方法：通過識別活前綴的 DFA 和【簡單向前看一個終結符】構造 SLR(1) 分析表。

如果我們的識別活前綴的 DFA 中存在移進-規約沖突、規約-規約沖突，都可以嘗試使用這個方法來解決沖突。（這里說【嘗試】，當然是因為 SLR 也只能解決一部分問題，並不是萬能的靈丹妙葯。。）

這里，我們拿前面那個 LR(0) 解決不了的文法來舉例

該文法不是 LR(0) 文法，但是是 SLR(1) 文法。

觀察上圖 DFA 中的狀態2，想像當我們的自動機正處於這個狀態：次棧頂已經規約為 T 了，棧頂也是當前的狀態 2 ，而當前剩餘輸入為 *。

如果這個自動機不會【往前多看一步】的話，那麼對處於這個狀態的自動機來說，看起來狀態 2 中的移進項目和規約項目都是可選的。這就是移進-規約沖突。

想要解決這個沖突，就輪到【往前多看一步】上場了——把當前剩餘輸入考慮進來，輔助進行項目的選擇：

對其他的沖突也使用同樣的方法進行判斷。

這種沖突性動作的解決辦法叫做 SLR(1) 解決辦法

准備工作部分，與 LR(0) 分析表的構造差不多：同樣使用每個項目集的狀態編號作為分析器的狀態編號，也就同樣用作行下標；同樣使用拓廣文法產生式作為 0 號產生式。

填表也和 LR(0) 類似，唯一的不同體現在對規約項的處理方法上：如果當前狀態有項目 A → α.aβ 和 A → α. ，而次棧頂此時是 α 且讀寫頭讀到的是 a，那麼當且僅當 a∈FOLLOW(A) 時，我們才會用 A → α 對 α 進行規約。

如果構造出來的表的每個入口都不含多重定義（也就是如上圖中表格那樣的，每個格子裡面最多隻有一個動作），那麼該表就是該文法的 SLR(1) 表，這個文法就是 SLR(1) 文法。使用 SLR(1) 表的分析器叫做一個 SLR(1) 分析器。

任意的二義文法都不能構造出 SLR(1) 分析表

例：懸空 else

例：

這里的 L 可以理解為左值，R 可以理解為右值

經過計算可以確定其 DFA 如下圖所示。

在 狀態4 中，由於 "=" 同時存在於 FOLLOW(L) 與 FOLLOW(R) 中，因此該狀態內存在移進-規約沖突，故該文法不是 SLR(1) 文法。

這樣的非二義文法可以通過增加向前看終結符的個數來解決沖突（比如LL(2)、LR(2)）但這會讓問題更加復雜，故一般不採用。而二義文法無論向前看多少個終結符都無法解決二義性。

E. 關於編譯原理

可以自己寫一個JPanel或者JComponent的子類，然後在子類中重寫paint方法，在裡面繪制背景圖片。下面的部分是從我的代碼里截出來的，不保證這樣能用，只是給你個大體的絲路。學會了這個後自己重寫組件就方便多了 public class ChessBoard extends JComponent{ private Image screen = null; public void paint(Graphics g) { if (screen != null) { g.drawImage(screen, (width - BOARDWIDTH) / 2, (height - BOARDHEIGHT) / 2, this); } else { screen = ChessBoard.this.createImage(BOARDWIDTH,BOARDHEIGHT); } } }

F. 編譯原理:考慮文法G[S]

考慮文法：
(1)消去左遞歸後:
S→a|∧|(T)
T→ST』
T』 →,ST』|ε
(2)計算每個非終結符的FIRST集合和FOLLOW集合:
FIRST(S)={a,∧,(}
FIRST(T)={ a,∧,(}
FIRST(T』)={,ε}
FOLLOW(S)={,#}
FOLLOW(T)={ )}
FOLLOW(T』)={ )}
預測分析表如下:
\x09a\x09∧\x09(\x09)\x09,\x09#
S\x09S→a\x09S→∧\x09S→(T)\x09\x09\x09
T\x09T→ST』\x09T→ST』\x09T→ST』\x09\x09\x09
T』\x09\x09\x09\x09T』 →ε\x09T』 →,ST』\x09
構造的預測分析表中沒有多重入口,所以改造後的文法是LL(1)文法.

G. 關於multiple defination of (多重定義 )的錯誤

1.
不要在.h裡面聲明變數，而是在.c(.cpp)裡面定義int mm=3;
然後在A.h裡面用extern int mm;

2.
extern不要賦值。

ps：還沒解決？
回樓上，沒用的，那個能防止重復include，但是不能解決這里的問題。
頭文件裡面是不提倡也不應該定義一個變數的。
如果熟悉VC的win32程序，就知道那個theApp也是放在cpp文件里的，而不是頭文件。

H. 關於vs2010運行多文件程序老是出現「fatal error LNK1169: 找到一個或多個多重定義的符號」的問題

頭文件是要聲明的，例如你的程序，在cpp結尾的程序的開頭都要寫#include"resource.h"就好了

I. 多重定義怎麼解決

鏈接時多重定義怎麼辦？一般解決方案是：只保留一個定義的地方就好了，這對強迫症，很友好！但往往有時又嫌麻煩，或者雜七雜八的的原因導致了，兩個定義都保留，但只讓鏈接時，只鏈接第一個遇到的定義函數！


其實吧，如果這多重定義的函數是存在於不同的庫，一般默認都只會找第一個遇到的庫裡面的函數就好了。

但是，因為，鏈接的最小單元一般是文件，.o。如果a.o和b.o同時存在test1()，但是a.o有test2()，b.o有test3()，結果這兩個介面函數都會被系統使用，那麼a.o和b.o就會被同時鏈接進去*。這就是為何會報多重定義的錯誤。

為了讓這種情況下，鏈接器還是不報錯，還是只會找第一個遇到的庫裡面的函數。可以使用以下參數：

-Wl,-z,multidefs或者Wl,'-z muldefs'，以及--allow-multiple-definition

讓ld在遇到重復定義時候，只處理第一個定義。