簡(jiǎn)介吉林大學(xué)計(jì)算機(jī)學(xué)院2022年編譯原理課程設(shè)計(jì)項(xiàng)目是一份基于C實(shí)現(xiàn)的SNL語(yǔ)言編譯器完整方案面向需要完成同類課程設(shè)計(jì)或系統(tǒng)學(xué)習(xí)詞法分析、語(yǔ)法分析、語(yǔ)義分析的本科生。項(xiàng)目采用LL(1)分析法構(gòu)建語(yǔ)法解析配合詞法分析器、語(yǔ)義分析器與符號(hào)表管理代碼模塊劃分清晰且由作者獨(dú)立完成、相似性低適合直接借鑒或二次拓展。壓縮包共91個(gè)文件以cpp、h源文件為主體涵蓋詞法分析、LL(1)語(yǔ)法分析、語(yǔ)義分析等關(guān)鍵模塊另含obj、exe、pdb等編譯產(chǎn)物、Visual Studio工程文件以及多組txt測(cè)試用例與錯(cuò)誤測(cè)試文本壓縮包整體142.28MB。內(nèi)容還涉及DS文法定義、保留字表、Token輸出與語(yǔ)義檢查用例工程配置完整便于構(gòu)建運(yùn)行和對(duì)照學(xué)習(xí)。已有1374人學(xué)習(xí)該資源對(duì)于希望獲得高分課程設(shè)計(jì)范例、深入理解編譯原理各階段實(shí)現(xiàn)的讀者具有較高的參考價(jià)值。1. SNL 語(yǔ)言編譯器課設(shè)源碼包為什么一個(gè)能拿滿績(jī)的參考值這個(gè)價(jià)某高校的編譯原理課程設(shè)計(jì)要求手寫(xiě)一個(gè) SNL 語(yǔ)言編譯器詞法、語(yǔ)法、語(yǔ)義三個(gè)階段全部真實(shí)跑通。SNL 是類 Pascal 的教學(xué)語(yǔ)言規(guī)模不大但保留字、算術(shù)表達(dá)式、函數(shù)調(diào)用、作用域和類型檢查一個(gè)不少。網(wǎng)上能翻到的參考要么是表達(dá)式計(jì)算器級(jí)別要么是公開(kāi)倉(cāng)庫(kù)里流傳爛大街的模板相似性高到不敢交。這份源碼包是 2022 年的完整交付C 編寫(xiě)從 config 下的 reserved_words.txt 到 LexAnalyzer.cpp再到 LL1.cpp、ParseLL1.cpp、SemAnalyzer.cpp 和 symtable.h整條鏈路全在還自帶 lex_error_test、sem_error_test、sem_correct_test 三組測(cè)試樣本。它適合正在寫(xiě)課設(shè)找不到語(yǔ)法樹(shù)接語(yǔ)義思路的人也適合已經(jīng)寫(xiě)完詞法、卡在 LL(1) 遞歸下降的人。下面我按自己復(fù)現(xiàn)的順序把文件、參數(shù)和坑一個(gè)個(gè)過(guò)一遍。2. 從 main.cpp 到 SemAnalyzer先盤(pán)清源碼包的數(shù)據(jù)流2.1 文件清單哪些是核心代碼哪些是 Visual Studio 編譯殘留解壓后是一個(gè)標(biāo)準(zhǔn)的 Visual Studio 工程Project2.sln 可以直接雙擊打開(kāi)。先把根目錄文件分個(gè)類避免一頭扎進(jìn) Debug 目錄里看那些 obj 和 pdb。文件/目錄定位說(shuō)明main.cpp程序入口串聯(lián)詞法、語(yǔ)法、語(yǔ)義三個(gè)階段讀源文件并輸出結(jié)果config / reserved_words.txt詞法配置保留字表LexAnalyzer 運(yùn)行時(shí)加載LexAnalyzer.h / LexAnalyzer.cpp詞法分析器產(chǎn)出 Token 流輸出到 tokens.txt / new_tokens.txtLL1.h / LL1.cppLL(1) 集合與沖突檢測(cè)計(jì)算 First/Follow 或維護(hù)預(yù)測(cè)邏輯ParseLL1.h / ParseLL1.cpp語(yǔ)法分析器遞歸下降主程序按文法產(chǎn)生式構(gòu)建語(yǔ)法樹(shù)ds_grammer.h文法定義產(chǎn)生式、終結(jié)符/非終結(jié)符編號(hào)TreeNode.h / TreeNode.cpp語(yǔ)法樹(shù)節(jié)點(diǎn)孩子兄弟鏈表供語(yǔ)義分析遍歷Kind2Str.h / Kind2Str.cpp可讀化輸出把節(jié)點(diǎn)枚舉轉(zhuǎn)成字符串調(diào)試輸出靠它SemAnalyzer.h / SemAnalyzer.cpp語(yǔ)義分析器符號(hào)表查詢、類型檢查、作用域管理symtable.h / symtable.cpp符號(hào)表記錄變量/函數(shù)的名字、類型、層級(jí)、偏移量test1.txt ~ test8.txt輸入樣本混合覆蓋詞法、語(yǔ)法、語(yǔ)義的正確與錯(cuò)誤用例lex_error_test / sem_error_test / sem_correct_test分類測(cè)試集分別用于驗(yàn)收詞法錯(cuò)誤、語(yǔ)義錯(cuò)誤和完全正確程序Debug 目錄下的 vc142.pdb、Project2.pdb、.obj、.tlog 全是 Visual Studio 的編譯殘留不影響理解邏輯。Project2.vcxproj.user 是用戶級(jí)配置換機(jī)器后建議直接刪掉讓 VS 重新生成。從 main.cpp 往下看標(biāo)準(zhǔn)數(shù)據(jù)流是讀入源文件 → LexAnalyzer 產(chǎn)出 Token 流 → ParseLL1 按文法組織語(yǔ)法樹(shù) → SemAnalyzer 遍歷語(yǔ)法樹(shù)并查符號(hào)表 → 最后把結(jié)果打印到 rc.txt 或 outout.txt。tokens.txt 和 new_tokens.txt 同時(shí)存在說(shuō)明詞法階段至少有兩種輸出模式常見(jiàn)的是普通 Token 流和帶行號(hào)位置的 Token 流。調(diào)試詞法錯(cuò)誤時(shí)這兩個(gè)文件能直接告訴你錯(cuò)誤發(fā)生在哪一行。2.2 詞法分析reserved_words.txt 與 LexAnalyzer.cpp 怎么配合很多人的詞法分析是把關(guān)鍵字硬編碼在幾十個(gè) if-else 里這份資源把保留字單獨(dú)放在 reserved_words.txt代碼里用映射表查類型。下面這個(gè)加載函數(shù)是這類實(shí)現(xiàn)的標(biāo)準(zhǔn)骨架和你最后在 cpp 里看到的結(jié)構(gòu)基本一致void LoadReservedWords(const std::string path, std::unordered_mapstd::string, int kw) { std::ifstream in(path); std::string word; int kind 0; while (in word) { // 文件每行格式保留字 類型編號(hào)例如if 1 else 2 while 3 // 這里把字符串和編號(hào)分別讀進(jìn) word 和 kind in kw[word]; } }這段代碼的邏輯說(shuō)明先用ifstream打開(kāi)保留字文件然后以空白為分隔符連續(xù)讀。第一次in word拿到保留字本身第二次in kw[word]讀入后面的整數(shù)并直接作為映射值。unordered_map的選擇有講究詞法分析階段每個(gè)標(biāo)識(shí)符都要查一次表哈希查找能保證均攤 O(1)不會(huì)成為瓶頸。這樣組織的好處一是新增一個(gè)保留字只需要改 txt不需要?jiǎng)哟a二是不容易出現(xiàn)滿屏魔法數(shù)字查重時(shí)的代碼觀感也干凈很多。LexAnalyzer 里識(shí)別標(biāo)識(shí)符的邏輯就是逐字符拼遇到字母開(kāi)頭就持續(xù)收集字母和數(shù)字拼完先查這個(gè)unordered_map查得到就是保留字查不到就是普通標(biāo)識(shí)符。Token 本身一般是struct Token { int type; std::string value; int line_no; };type 枚舉定義在 macro.h 或 LexAnalyzer.h 里。注意 reserved_words.txt 的編碼必須和源文件一致。最常見(jiàn)的坑是 UTF-8 帶 BOM導(dǎo)致第一個(gè)關(guān)鍵字額外多出一個(gè)不可見(jiàn)字符后面避坑章會(huì)專門(mén)講。2.3 語(yǔ)法樹(shù)TreeNode 的孩子兄弟鏈表與 Kind2Str 的可讀化輸出一段程序光有 Token 流不夠語(yǔ)義分析要在一個(gè)能表達(dá)嵌套結(jié)構(gòu)的樹(shù)上跑。TreeNode.cpp 用的是孩子兄弟表示法節(jié)點(diǎn)骨架長(zhǎng)這樣struct TreeNode { int kind; // 節(jié)點(diǎn)類型對(duì)應(yīng) Kind2Str 里的枚舉名 TreeNode* child; // 第一個(gè)子節(jié)點(diǎn) TreeNode* sibling; // 右兄弟節(jié)點(diǎn) std::string value; // 標(biāo)識(shí)符名或字面量 int line_no; // 來(lái)源行號(hào)語(yǔ)義報(bào)錯(cuò)全靠它 };為什么不用子節(jié)點(diǎn)數(shù)組因?yàn)?SNL 文法里 if 語(yǔ)句的子節(jié)點(diǎn)個(gè)數(shù)不固定有 else 是三個(gè)子節(jié)點(diǎn)沒(méi)有 else 是兩個(gè)用孩子兄弟鏈表可以動(dòng)態(tài)掛節(jié)點(diǎn)遍歷函數(shù)統(tǒng)一走child和sibling兩條指針即可。Kind2Str.cpp 就是把 kind 整數(shù)映射成字符串比如某個(gè)節(jié)點(diǎn) kind 是 101打印出來(lái)是AddExpr比對(duì)輸出文件時(shí)一目了然。打印語(yǔ)法樹(shù)的遞歸函數(shù)一般長(zhǎng)這樣void PrintTree(TreeNode* node, int depth) { while (node ! nullptr) { // 縮進(jìn)表示層級(jí)Kind2Str 負(fù)責(zé)把枚舉轉(zhuǎn)成可讀名 std::cout std::string(depth * 2, ) Kind2Str(node-kind) node-value std::endl; PrintTree(node-child, depth 1); node node-sibling; } }depth是當(dāng)前樹(shù)深度每次遞歸子節(jié)點(diǎn)時(shí)加一sibling在同一層橫向遍歷。main.cpp 遍歷語(yǔ)法樹(shù)后輸出到 rc.txt 或 outout.txt對(duì)照輸出文件就能驗(yàn)證遞歸下降函數(shù)的調(diào)用順序是否正確。3. 語(yǔ)法分析LL(1) 遞歸下降如何組織文法與預(yù)測(cè)3.1 為什么選 LL(1) 而不是 LR課設(shè)文法規(guī)模決定的取舍從文件命名能看出設(shè)計(jì)意圖LL1.h/cpp 帶著預(yù)測(cè)分析的味道ParseLL1.cpp 是實(shí)際的遞歸下降入口。SNL 這種課程語(yǔ)言文法一般就四五十條產(chǎn)生式用 LL(1) 手工寫(xiě)一組遞歸下降函數(shù)完全可控。LR 系雖然能處理更多文法但要引入自動(dòng)生成工具課設(shè)老師更希望你解釋清楚預(yù)測(cè)邏輯所以 LL(1) 是這類資源的主流選擇。LL1.cpp 通常負(fù)責(zé)計(jì)算 First/Follow 集合或者在建表過(guò)程中發(fā)現(xiàn)沖突時(shí)給出提示ParseLL1.cpp 按非終結(jié)符寫(xiě)函數(shù)一個(gè)非終結(jié)符對(duì)應(yīng)一個(gè) C 函數(shù)。ds_grammer.h 里的產(chǎn)生式就是這些函數(shù)的直接來(lái)源比如expr → term { (|-) term }對(duì)應(yīng)的就是下面這樣的函數(shù)。3.2 四則運(yùn)算表達(dá)式的遞歸下降一個(gè)可直接抄的結(jié)構(gòu)算術(shù)表達(dá)式是最典型的一層。下面的代碼是遞歸下降實(shí)現(xiàn)里必然會(huì)出現(xiàn)的結(jié)構(gòu)你會(huì)在 ParseLL1.cpp 里看到它的變體TreeNode* ParseExpr() { TreeNode* left ParseTerm(); // 先解析優(yōu)先級(jí)更高的項(xiàng) while (cur_token TOKEN_PLUS || cur_token TOKEN_MINUS) { TokenKind op cur_token; // 保存當(dāng)前運(yùn)算符 Match(cur_token); // 吃掉當(dāng)前運(yùn)算符 TreeNode* right ParseTerm(); // 解析右側(cè)操作數(shù) TreeNode* parent CreateNode(KIND_BIN_EXPR); parent-child left; // 左操作數(shù)掛到 child left-sibling right; // 右操作數(shù)掛到 sibling parent-value TokenToText(op); // 記錄運(yùn)算符文本 left parent; // 新節(jié)點(diǎn)作為左側(cè)繼續(xù)循環(huán) } return left; }邏輯說(shuō)明ParseExpr先調(diào)ParseTerm因?yàn)槌顺齼?yōu)先級(jí)高于加減這步是文法層級(jí)決定的。while循環(huán)處理同優(yōu)先級(jí)運(yùn)算符的左結(jié)合每次構(gòu)造一個(gè)KIND_BIN_EXPR父節(jié)點(diǎn)把已有的left掛在child新解析出來(lái)的right掛在sibling。因?yàn)?TreeNode 是孩子兄弟結(jié)構(gòu)左操作數(shù)右操作數(shù)實(shí)際上是一條鏈而不是兩個(gè)獨(dú)立指針。這個(gè)循環(huán)不會(huì)產(chǎn)生左遞歸因?yàn)樗盐姆ɡ锏淖筮f歸改寫(xiě)成了迭代。參數(shù)說(shuō)明cur_token是全局當(dāng)前 TokenMatch斷言當(dāng)前 Token 類型等于參數(shù)并推進(jìn)到下一個(gè)。每個(gè)非終結(jié)符函數(shù)都必須在入口處至少調(diào)一次Match或NextToken否則可能死循環(huán)。3.3 if-else 懸空與同步恢復(fù)語(yǔ)法錯(cuò)誤后還能繼續(xù)往下跑if 語(yǔ)句是另一個(gè)高頻踩坑點(diǎn)。LL(1) 遞歸下降處理 else 懸空靠的是前看一個(gè) TokenTreeNode* ParseIfStmt() { Match(TOKEN_IF); TreeNode* cond ParseExpr(); // 條件表達(dá)式 Match(TOKEN_THEN); TreeNode* thenStmt ParseStmt(); // 必選分支 TreeNode* elseStmt nullptr; if (cur_token TOKEN_ELSE) { // 前看一個(gè) Token 決定分支 Advance(); elseStmt ParseStmt(); // 可選分支 } Match(TOKEN_END); return BuildIfNode(cond, thenStmt, elseStmt); }邏輯說(shuō)明解析完 then 分支后并不急著消費(fèi)TOKEN_ELSE而是看當(dāng)前 Token 是不是 else。是則額外解析一個(gè)語(yǔ)句不是則直接匹配END。這樣嵌套的 if-else 會(huì)自動(dòng)就近配對(duì)不會(huì)出現(xiàn)懸空 else。注意這里ParseStmt的調(diào)用位置決定了遞歸深度遇到復(fù)雜嵌套時(shí)要確認(rèn)每個(gè)函數(shù)都在推進(jìn) Token。語(yǔ)法錯(cuò)誤不能一遇到就停否則一個(gè)錯(cuò)誤只報(bào)一行后面全被屏蔽。常見(jiàn)做法是同步恢復(fù)Match失敗時(shí)從出錯(cuò)位置跳過(guò) Token直到遇到分號(hào)、END、ELSE這類同步記號(hào)再重新嘗試。test1.txt、test2.txt 這類輸入里故意放了幾處缺分號(hào)或括號(hào)不匹配輸出能看出行號(hào)能報(bào)到哪里這就是同步恢復(fù)在起作用。調(diào)試時(shí)重點(diǎn)看 ParseLL1.cpp 里所有return false或主動(dòng)Abort的地方錯(cuò)誤信息通常會(huì)標(biāo)unexpected token at line N。4. 語(yǔ)義分析與符號(hào)表symtable 與 SemAnalyzer 如何完成作用域檢查4.1 符號(hào)表設(shè)計(jì)層級(jí)、類型、偏移量怎么填語(yǔ)義分析的核心是符號(hào)表和類型檢查。symtable.h 里的符號(hào)條目通常包含名字、類型、層級(jí)和偏移量。作用域是一個(gè)棧全局在最底層進(jìn)入函數(shù)壓一層進(jìn)入內(nèi)層塊再壓一層。SNL 里同名變量能不能重復(fù)聲明就看棧頂那一層有沒(méi)有同名條目。一個(gè)可用的符號(hào)表?xiàng)l目結(jié)構(gòu)長(zhǎng)這樣struct Symbol { std::string name; // 變量名或函數(shù)名 int type; // 0int, 1boolean, 2array int level; // 0 是全局1 是第一個(gè)函數(shù)級(jí) int offset; // 局部變量在棧幀里的偏移或數(shù)組長(zhǎng)度 bool is_param; // 是形參就在函數(shù)入口登記 };符號(hào)表按層分組常見(jiàn)做法是std::vectorstd::vectorSymbol scopes。聲明變量時(shí)push_back到scopes[current_level]退出代碼塊時(shí)把整層pop_back。level字段不是必須的因?yàn)閺膕copes的下標(biāo)能推出來(lái)但保留它能讓調(diào)試信息更友好。4.2 聲明檢查和類型檢查落地一邊遍歷語(yǔ)法樹(shù)一邊查表語(yǔ)義分析從語(yǔ)法樹(shù)根節(jié)點(diǎn)開(kāi)始遞歸下降和語(yǔ)法分析不同它不再消費(fèi) Token而是消費(fèi) TreeNode。賦值語(yǔ)句的類型檢查是一個(gè)典型例子void CheckAssign(TreeNode* node) { Symbol* left FindSymbol(node-child-value); // 左值查符號(hào)表 if (left nullptr) { SemError(variable %s not declared, node-child-value.c_str()); // 未聲明變量 return; } int rightType ExprType(node-child-sibling); // 遞歸求右式類型 if (left-type ! rightType) { SemError(type mismatch at line %d, node-line_no); } }邏輯說(shuō)明FindSymbol從最內(nèi)層作用域向外層查因?yàn)閮?nèi)層同名變量會(huì)遮蔽外層。這和聲明重復(fù)檢查正好相反聲明查重只看當(dāng)前層類型檢查要看所有可見(jiàn)層。這兩個(gè)方向很容易搞反我的習(xí)慣是先讀懂函數(shù)名Find和CheckDecl分開(kāi)寫(xiě)不要把兩個(gè)語(yǔ)義混進(jìn)一個(gè)函數(shù)。數(shù)組下標(biāo)檢查是另一個(gè)加分點(diǎn)取 array 類型的長(zhǎng)度比較下標(biāo)表達(dá)式是否越界。課設(shè)不要求運(yùn)行時(shí)求值但下標(biāo)是常量時(shí)可以當(dāng)場(chǎng)報(bào)越界這類實(shí)現(xiàn)會(huì)明顯提升代碼完成度。4.3 三組測(cè)試樣本為什么錯(cuò)誤測(cè)試和正確測(cè)試同樣重要資源里的測(cè)試文件夾分三個(gè)這是最容易忽視的財(cái)富。lex_error_test 里是詞法錯(cuò)誤樣本比如非法字符、未閉合注釋sem_error_test 是能過(guò)語(yǔ)法但過(guò)不了語(yǔ)義的樣本比如未聲明變量、類型不匹配sem_correct_test 是應(yīng)該完全通過(guò)的合法程序。拿到源碼后最好按順序跑判斷標(biāo)準(zhǔn)很明確正確樣本輸出不能有錯(cuò)誤標(biāo)記錯(cuò)誤樣本每個(gè)都要在正確的行號(hào)上報(bào)錯(cuò)。如果你發(fā)現(xiàn)某個(gè)詞法錯(cuò)誤樣本被語(yǔ)法分析攔截了說(shuō)明詞法階段對(duì)非法字符沒(méi)有攔截干凈如果某個(gè)語(yǔ)義錯(cuò)誤樣本到最后都沒(méi)有報(bào)錯(cuò)說(shuō)明 SemAnalyzer 的某個(gè)檢查分支根本沒(méi)被走到。三組樣本一起跑能驗(yàn)證編譯器不只是好路徑上不崩潰。5. 常見(jiàn)問(wèn)題排查拿這份資源跑通時(shí)最容易翻車(chē)的五個(gè)點(diǎn)5.1 現(xiàn)象編譯成功但 Debug 目錄里沒(méi)有新生成的 Project2.exe按下 F7 編譯成功運(yùn)行卻發(fā)現(xiàn)跑的是舊 exe或者 Debug 目錄下根本沒(méi)有 exe。這個(gè)情況我遇到過(guò)不止一次。原因是工程被復(fù)制后.vcxproj 里的輸出目錄還指向原作者機(jī)器的絕對(duì)路徑比如D:\someone\Debug你編譯到別人目錄去了。解決方式很直接右鍵 Project2 屬性 → 常規(guī) → 輸出目錄改成$(SolutionDir)Debug\目標(biāo)文件名改成Project2.exe然后重新生成。改完后看輸出窗口的編譯日志確認(rèn)傳到的是你當(dāng)前工程的 Debug 目錄。5.2 現(xiàn)象源碼里明明有 if、while詞法分析卻全部識(shí)別成標(biāo)識(shí)符代碼里讀保留字表時(shí)第一個(gè)關(guān)鍵字永遠(yuǎn)匹配不上后面幾個(gè)正常。原因是 reserved_words.txt 用了 UTF-8 帶 BOM 編碼BOM 頭在文件開(kāi)頭加了一個(gè)不可見(jiàn)字符導(dǎo)致第一個(gè)單詞讀出來(lái)是\xEF\xBB\xBFif和代碼里的if字符串不同。另一個(gè)常見(jiàn)變體是 Windows 行尾的\r沒(méi)去掉行末單詞多一個(gè)回車(chē)符。解決方式是用 Visual Studio 的文件 → 高級(jí)保存選項(xiàng)把 reserved_words.txt 改成 UTF-8 無(wú) BOM同時(shí)養(yǎng)成習(xí)慣讀入每個(gè)單詞后做一次裁剪去掉非打印字符。從那以后我每次加載外部配置文件都會(huì)先打印一條調(diào)試信息看看第一個(gè)鍵到底是什么。5.3 現(xiàn)象語(yǔ)法分析跑到一半棧溢出或者直接死循環(huán)遞歸下降最常見(jiàn)的死循環(huán)來(lái)自左遞歸文法。比如你照著教科書(shū)寫(xiě)expr → expr term函數(shù)里第一句又調(diào)ParseExpr自己Token 還沒(méi)消費(fèi)就無(wú)限遞歸下去棧很快爆掉。解決方式是把左遞歸改寫(xiě)成迭代ParseExpr里先ParseTerm再用 while 循環(huán)吃掉和-這樣每個(gè)循環(huán)都會(huì)消耗一個(gè) Token永遠(yuǎn)不會(huì)原地打轉(zhuǎn)。另外還有一種隱蔽情況某個(gè)非終結(jié)符函數(shù)里漏了Match連續(xù)調(diào)用同一個(gè)函數(shù)兩次卻沒(méi)有推進(jìn)cur_token。排查技巧很簡(jiǎn)單在每個(gè)非終結(jié)符函數(shù)入口加一行斷點(diǎn)觀察cur_token的 type 有沒(méi)有變化沒(méi)變化的函數(shù)就是兇手。5.4 現(xiàn)象語(yǔ)義分析把內(nèi)層作用域的同名變量誤判成重復(fù)聲明內(nèi)層聲明了一個(gè)與外層同名的變量編譯器直接報(bào)重復(fù)聲明。原因是符號(hào)表沒(méi)有真正實(shí)現(xiàn)作用域棧進(jìn)函數(shù)前沒(méi)壓新層所有名字都堆在同一個(gè)全局表里。解決方式是把scopes.push_back({})放到函數(shù)入口退出前scopes.pop_back()。聲明查重只遍歷scopes.back()也就是當(dāng)前層查找符號(hào)則從back()往 0 方向遍歷。如果把這兩個(gè)方向?qū)懛淳蜁?huì)出現(xiàn)外層變量找不到、內(nèi)層同名變量全報(bào)錯(cuò)的情況。調(diào)試時(shí)可以在符號(hào)表每次 push/pop 時(shí)打印當(dāng)前作用域大小一眼就能看出棧有沒(méi)有正常退層。5.5 現(xiàn)象用新版 Visual Studio 打開(kāi)工程提示 v142 工具集未安裝Debug 目錄里的 vc142.pdb 已經(jīng)暴露了工程生成環(huán)境v142 是 Visual Studio 2019 的工具集。如果你用 VS2022 直接打開(kāi)會(huì)提示找不到 v142 生成工具編譯直接失敗。解決方式有三個(gè)任選其一裝 VS2019 的生成工具在項(xiàng)目屬性 → 常規(guī) → 平臺(tái)工具集里改成 v143也就是 VS2022 自帶工具集或者直接改 .vcxproj 文件里的PlatformToolsetv142/PlatformToolset為v143再重新加載工程。順手檢查一下 Windows SDK 版本如果機(jī)器上只有新 SDK把屬性里的 SDK 版本改成已安裝的那個(gè)別讓它自動(dòng)選擇錯(cuò)誤的版本。6. 最后一關(guān)用三組測(cè)試樣本把自己的交付變成證據(jù)分享一個(gè)能讓編譯器課設(shè)少走彎路的驗(yàn)收習(xí)慣。拿到這份資源后我先把 main.cpp 里默認(rèn)讀取的文件名改成從命令行參數(shù)讀取然后寫(xiě)一個(gè)腳本把三組測(cè)試樣本全部跑一遍而不是在 IDE 里手動(dòng)一個(gè)個(gè)改文件名。這個(gè)改動(dòng)很小收益卻很直接它可以自動(dòng)跑完幾十個(gè)樣本并用文件對(duì)比工具檢查輸出。# 以 test5.txt 為輸入把結(jié)果寫(xiě)到 out5.txt Project2.exe test5.txt out5.txt # 用 fc 對(duì)比實(shí)際輸出與期望輸出 fc out5.txt expected5.txt跑完后的檢查清單我每次都會(huì)過(guò)一遍lex_error_test 里的每個(gè)樣本是否都在詞法階段報(bào)錯(cuò)sem_error_test 里的未聲明變量和類型不匹配是否都有正確的行號(hào)sem_correct_test 里的合法程序是否一次通過(guò)且輸出語(yǔ)法樹(shù)結(jié)構(gòu)完整。如果某個(gè)樣本的錯(cuò)誤出現(xiàn)在錯(cuò)誤的階段比如詞法錯(cuò)誤被語(yǔ)法分析彈出那說(shuō)明詞法階段的攔截不夠優(yōu)先回 LexAnalyzer 找原因而不是在 ParseLL1 里打補(bǔ)丁。一開(kāi)始我只盯著正確樣本跑覺(jué)得能跑通就等于完成。后來(lái)某次調(diào)試一個(gè)數(shù)組下標(biāo)越界正確樣本全都正常語(yǔ)義錯(cuò)誤樣本卻一個(gè)都沒(méi)攔住我才意識(shí)到反面測(cè)試才是判斷編譯器脆不脆的關(guān)鍵。從那以后我每拆一份編譯器源碼都會(huì)先看它的錯(cuò)誤測(cè)試樣本有沒(méi)有被歸類好沒(méi)有的話自己補(bǔ)。這個(gè)習(xí)慣幫我避開(kāi)了很多正例全過(guò)、反例全崩的假完成。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取