簡介面向南京航空航天大學數(shù)據(jù)結構課程設計的一套原創(chuàng)代碼與報告合集適合正在修讀數(shù)據(jù)結構或準備課程設計答辯的本科學生。內容覆蓋多個典型題目包括基數(shù)排序、希爾排序、歸并排序、最小生成樹、哈夫曼編碼、家譜管理等每個題目均提供C源代碼及對應數(shù)據(jù)文件部分配有可執(zhí)行的exe程序便于直接運行驗證txt文件多為測試數(shù)據(jù)或日志輸出可幫助理解算法處理過程。壓縮包共76個文件以cpp源文件為主36個另含31個txt數(shù)據(jù)與結果記錄、6個exe可執(zhí)行文件、1份docx課程設計報告整體大小6.2MB。報告闡述設計思路與代碼結構能幫助讀者快速理解實現(xiàn)細節(jié)并遷移到自己的作業(yè)中。已有2788人學習下載適合希望獲得完整項目參考和代碼指導的數(shù)據(jù)結構學習者。1. 南京航空航天大學數(shù)據(jù)結構課程設計代碼加報告到底在考察什么南京航空航天大學數(shù)據(jù)結構課程設計最終交付物就兩個代碼和報告。很多同學把兩周時間全花在調通代碼上答辯時被一句“這個算法復雜度是多少”問得說不出話也有人報告寫了四五十頁程序一運行就崩。這門課真正考察的是你能不能把一個數(shù)據(jù)結構問題從選題、設計、實現(xiàn)到驗證完整走一遍。這篇文章就按這條線把選題怎么選、代碼怎么寫、報告怎么組織、答辯前怎么檢查講清楚適合正在趕設計周的低年級本科生。2. 選題是第一步哪些數(shù)據(jù)結構撐得起評分和答辯課程設計的評分一般不是“跑通就滿分”而是看題目涉及的數(shù)據(jù)結構種類、算法難度、代碼模塊化和報告完成度。選題直接決定后面所有工作量的上限。我見過太多人選了個鏈表增刪改查代碼三天寫完結果報告撐不滿二十頁答辯老師問兩句就沒話聊了。反過來選了圖論題又遲遲不動手最后一周通宵趕工翻車的也有。先把選題池子列清楚再談怎么選。2.1 八類高頻選題與對應數(shù)據(jù)結構覆蓋各高校數(shù)據(jù)結構課程設計題目翻來覆去就是那十幾類南航歷屆題目也大多落在這個范圍內。我把最常見的整理成一張表方便你對照自己的編程水平選。選題方向核心數(shù)據(jù)結構涉及算法/操作答辯常見追問工作量評估圖書/物品管理系統(tǒng)順序表、鏈表、哈希表增刪改查、按關鍵字查找查找效率怎么提升、哈希沖突怎么處理中校園導航/公交查詢圖鄰接矩陣/鄰接表Dijkstra、Floyd、DFS/BFS 遍歷頂點數(shù)變大后性能如何退化中大Huffman 編碼壓縮二叉樹、優(yōu)先隊列建樹、編碼、解碼、位運算編碼唯一性怎么保證、解碼邊界大迷宮求解棧、隊列DFS/BFS、回溯為什么 BFS 找到的路徑最短中表達式求值棧中綴轉后綴、運算符優(yōu)先級括號、負數(shù)、除零怎么處理中排序算法對比演示順序表快速排序、堆排序、歸并排序穩(wěn)定性、最壞復雜度、數(shù)據(jù)規(guī)模影響中學生成績管理順序表、索引二分查找、排序、文件存取上萬條記錄時性能怎么保證中小雙端隊列應用模擬雙端隊列 deque受限隊列、滑動窗口和普通隊列/std::queue 的差異小表里工作量評估是按一個正常設計周兩周左右估算的。鏈表和雙端隊列這類題目代碼量少適合時間緊張或者只想穩(wěn)過的人圖論、Huffman 這類題目能拿高分代價是代碼和報告都要投入更多。排序對比題是個特殊情況代碼不難但報告里要寫的數(shù)據(jù)分析和圖表特別多適合愿意做測試記錄的人不太適合只想趕緊交差的人。2.2 為什么我建議選圖論應用類選題而不是鏈表和排序如果時間允許我的建議一直是選“校園導航”這類圖論應用題。原因不是它代碼最難而是它能讓評分和答辯都舒服。數(shù)據(jù)結構覆蓋得很全存儲結構要對比鄰接矩陣和鄰接表遍歷要講 DFS/BFS核心算法 Dijkstra 能往堆優(yōu)化上引復雜度從 O(V2) 到 O((VE)logV) 有層次感。報告里可寫的章節(jié)自然豐富答辯時老師問“為什么用這個結構”答案也不是一句“書上說這樣寫”能糊弄過去的。反過來看兩類常見坑。第一類是圖書管理系統(tǒng)代碼寫完就是 CRUD核心數(shù)據(jù)結構只有順序表和哈希表報告寫到最后全是“登錄”“注冊”這類業(yè)務功能跟數(shù)據(jù)結構關系不大評分上限很低。第二類是排序算法對比快速排序代碼本身不難但要把幾種排序在不同數(shù)據(jù)規(guī)模下的表現(xiàn)測出來需要做大量測試記錄很多人最后只貼一段運行截圖草草了事。圖論題的優(yōu)點在于它的“下限”就比其他題高即使你只做了基礎 Dijkstra代碼也能拆出建圖、遍歷、查詢三個模塊報告每一章都有實質內容可寫。另外要說一條實在的選圖論題的人多意味著代碼網(wǎng)上到處都是查重壓力也大。想拿高分就別把公開源碼直接搬下來哪怕自己重寫一遍、換一種存儲結構答辯時都能講出區(qū)別。2.3 把任務書翻譯成技術指標選型自檢表拿到題目后別急著寫代碼先把任務書里的一句話需求翻譯成技術參數(shù)。舉例說“設計一個校園導航系統(tǒng)實現(xiàn)任意兩地點最短路徑查詢”可以拆成數(shù)據(jù)規(guī)模約 10~30 個景點、40~60 條道路頂點和邊固定寫入數(shù)據(jù)文件存儲結構頂點少邊也不多但為了演示讀文件建圖用鄰接表更直觀核心算法單源最短路徑Dijkstra 優(yōu)先隊列優(yōu)化交互方式命令行菜單提供瀏覽全圖、查詢最短路徑、退出三個功能邊界條件輸入不存在的編號、查不到路徑、文件缺失都要有明確提示。動工前用這張自檢表問自己四件事能避免做到一半才發(fā)現(xiàn)題目撐不起設計自檢項通過標準數(shù)據(jù)結構覆蓋至少兩類結構如 圖 優(yōu)先隊列模塊拆分能拆出 3 個以上相互獨立的函數(shù)/類算法復雜度核心算法能寫出時間、空間復雜度演示數(shù)據(jù)能構造一組“好看”的輸入路徑有繞行、有短距對比如果這四項里有兩項打勾困難說明題目偏小建議主動加一個功能模塊比如在最短路徑之外再加一個“可達性判斷”或“全圖遍歷展示”。這樣報告里的“概要設計”一節(jié)才有內容可寫。3. 用 C 把核心代碼跑起來校園導航系統(tǒng)的完整實現(xiàn)路徑這一章把校園導航系統(tǒng)的最小可運行版本完整走一遍。選 C 是因為南航這類課程設計傳統(tǒng)上偏 C/C而且指針、引用、STL 容器都能在答辯里講出東西。如果你學校允許 Java 或 Python核心思路一樣只是存儲結構和堆優(yōu)化的寫法不同。這里先給工程目錄再逐步給出建圖、Dijkstra、交互菜單三塊代碼。3.1 工程目錄與頭文件劃分模塊化是你答辯的第一道護城河常見做法是建一個干凈工程目錄源碼、數(shù)據(jù)文件、報告分開而不是把所有代碼堆在一個 main.cpp 里。GraphNav/ ├── main.cpp ├── graph.hpp ├── graph.cpp ├── data.txt └── README.txtgraph.hpp 放類的聲明graph.cpp 放實現(xiàn)main.cpp 只寫界面交互。頭文件和實現(xiàn)分離的好處有兩個一是編譯時改動局部不用全量重編二是答辯被問“你這個工程怎么組織的”時你直接說“按聲明、實現(xiàn)、入口三層分”比手忙腳亂翻代碼強。注意每個 .cpp 文件頂部把頭文件和用到的標準庫補齊graph.cpp 里至少 includefstream、queue、functionalmain.cpp 里 includegraph.hpp和iostream。這種細節(jié)看起來小但第一次在別人機器上編譯時缺 include 的報錯最容易讓人懵。3.2 鄰接表建圖與數(shù)據(jù)文件讀取核心代碼塊與參數(shù)說明先看 graph.hpp 里的類設計。為什么用類而不是全局函數(shù)因為頂點名字、鄰接表、距離數(shù)組這些狀態(tài)需要共享類把它們綁在一起析構的時候 vector 會自動釋放內存你不需要手寫 delete答辯被問“內存誰釋放”時可以直接回答“STL 容器自動管理”。// graph.hpp #ifndef GRAPH_HPP #define GRAPH_HPP #include vector #include string #include utility class GraphNav { public: GraphNav() default; bool loadFromFile(const std::string filename); void printGraph() const; void printShortestPath(int src, int dst) const; private: int vertexCount_ 0; std::vectorstd::string names_; // 頂點名稱下標即編號 std::vectorstd::vectorstd::pairint, int adj_; // 鄰接表鄰接點, 邊權 void dijkstra(int src, std::vectorint dist, std::vectorint prev) const; }; #endif關鍵參數(shù)adj_是 vector 套 vector外層下標是頂點編號內層每個元素是pairint,intfirst 存鄰接點編號second 存邊權。這套結構寫起來比“結構體指針 手動 new 節(jié)點”省事得多而且畫圖和查路徑時遍歷也直觀。接下來看數(shù)據(jù)文件和讀取函數(shù)。data.txt 的格式我建議固定成三塊第一行兩個整數(shù)分別是頂點數(shù)和邊數(shù)接下來 n 行每行一個景點名再接下來 m 行每行三個整數(shù) u、v、w表示一條無向邊。5 6 校門 圖書館 教學樓 食堂 體育館 0 1 400 1 2 300 0 3 200 2 3 500 3 4 150 2 4 600對應的讀取函數(shù)bool GraphNav::loadFromFile(const std::string filename) { std::ifstream fin(filename); if (!fin.is_open()) return false; int n, m; fin n m; vertexCount_ n; names_.resize(n); adj_.assign(n, {}); std::string line; std::getline(fin, line); // 吞掉第一行末尾的換行符 for (int i 0; i n; i) { std::getline(fin, names_[i]); } for (int i 0; i m; i) { int u, v, w; fin u v w; adj_[u].push_back({v, w}); adj_[v].push_back({u, w}); // 無向圖正反各加一次 } return true; }這段代碼有三個容易翻車的點。第一第一行讀完 n 和 m 后換行符殘留在緩沖區(qū)必須用getline先吞掉否則接下來讀取景點名會把空行讀進去。第二頂點編號我統(tǒng)一從 0 開始和數(shù)組下標對齊如果你題目里給的編號從 1 開始要么讀入時減一要么在adj_前面墊一個空元素千萬別在查詢函數(shù)里到處減一遲早出 bug。第三文件打開失敗返回 false調用方要據(jù)此給用戶提示而不是繼續(xù)往下跑否則后續(xù)對空數(shù)組操作會直接越界。3.3 Dijkstra 最短路徑priority_queue 版本與復雜度計算核心算法用堆優(yōu)化的 Dijkstra。這里不貼樸素 O(V2) 版本因為課程設計答辯時堆優(yōu)化版本更容易引出“復雜度怎么算”“數(shù)據(jù)量大怎么辦”這類加分問題。代碼里的結構體綁定需要 C17 支持如果用 Dev-C 舊版編譯器請改成pairint,int top pq.top(); int d top.first; int u top.second;。void GraphNav::dijkstra(int src, std::vectorint dist, std::vectorint prev) const { const int INF 1e9; // 距離上界 dist.assign(vertexCount_, INF); prev.assign(vertexCount_, -1); dist[src] 0; using Pair std::pairint, int; // 當前距離, 頂點編號 std::priority_queuePair, std::vectorPair, std::greaterPair pq; // 小頂堆距離小的先出隊 pq.push({0, src}); while (!pq.empty()) { auto [d, u] pq.top(); pq.pop(); if (d ! dist[u]) continue; // 惰性刪除跳過過期狀態(tài) for (const auto [v, w] : adj_[u]) { if (dist[u] w dist[v]) { dist[v] dist[u] w; prev[v] u; pq.push({dist[v], v}); } } } }參數(shù)說明prev數(shù)組存的是“到達當前點的前一個頂點編號”用于最后反推路徑INF取 1e9 是因為頂點數(shù)和邊權都在千級以內int 不會溢出也不要取INT_MAX這類極值否則松弛時dist[u] w可能溢出變負數(shù)。if (d ! dist[u]) continue;是堆優(yōu)化的經(jīng)典寫法一個頂點可能被重復入隊多次但只有距離最新的一次才需要處理舊狀態(tài)直接跳過省去手工維護 visited 數(shù)組的麻煩。復雜度方面每個頂點入隊出隊一次每條邊在松弛時被掃描一次再加上堆操作的 logV總時間是 O((VE)logV)空間 O(VE)。答辯時這幾句話要背熟。另外要提前想清楚一個坑Dijkstra 不能處理負權邊因為負權會讓“當前距離最小”的貪心假設失效。如果題目里有負權那就得換 Bellman-Ford 或 SPFA課程設計要求里一般不會出這種題但老師會問。打印最短路徑的函數(shù)用 prev 反向回溯再逆序輸出void GraphNav::printShortestPath(int src, int dst) const { std::vectorint dist, prev; dijkstra(src, dist, prev); if (dist[dst] (int)1e9) { std::cout 兩個地點之間沒有通路\n; return; } std::vectorint path; for (int cur dst; cur ! -1; cur prev[cur]) { path.push_back(cur); // 從終點一路向前找得到的是反序 } for (int i (int)path.size() - 1; i 0; --i) { std::cout names_[path[i]]; if (i 0) std::cout - ; } std::cout \n總長度: dist[dst] \n; }這里dist[dst] (int)1e9是判斷不可達的常用辦法前提是邊權不為 1e9 且不會疊加到 1e9。輸出路徑用逆序遍歷而不是遞歸因為遞歸在路徑長時會壓棧雖然本例規(guī)模小無所謂但答辯說“我用了迭代回溯而非遞歸”能顯得你考慮過邊界。3.4 菜單與交互設計演示用的基本輸入路徑最后是 main.cpp 里的交互菜單。課程設計演示只需要做到“夠用”菜單清晰、輸入有提示、退出能正常跳循環(huán)。不要在這上面堆功能比如搞圖形界面、鼠標點擊除非老師明確說加分。#include graph.hpp #include iostream int main() { GraphNav nav; if (!nav.loadFromFile(data.txt)) { std::cout 打開 data.txt 失敗請確認文件與程序在同一目錄\n; return 1; } while (true) { std::cout \n 校園導航 \n; std::cout 1. 瀏覽全圖\n2. 查詢最短路徑\n0. 退出\n; int op; std::cin op; if (op 0) break; if (op 1) { nav.printGraph(); } else if (op 2) { int src, dst; std::cout 輸入起點和終點編號0~ 4 : ; std::cin src dst; nav.printShortestPath(src, dst); } else { std::cout 無效選項請重新輸入\n; } } return 0; }演示時最穩(wěn)的走法是先選 1 瀏覽全圖讓老師看到數(shù)據(jù)加載正常再查一條路徑稍長的點對比如從校門到體育館讓輸出至少有四五個節(jié)點顯得算法真的在找路最后輸入一個錯誤編號展示程序不會崩。這套順序在答辯前一晚自己走幾遍形成肌肉記憶。菜單里選項編號從 0 開始演示前心里有數(shù)別現(xiàn)場去數(shù)景點編號。4. 課程設計報告怎么寫從任務書到附錄的完整骨架代碼寫完報告占另一半分數(shù)。南航這類課程設計的報告沒有統(tǒng)一模板但評閱邏輯是一致的老師先看需求分析是否清楚再看概要設計里數(shù)據(jù)結構選型有沒有理由然后翻詳細設計和測試最后掃一眼總結和附錄。很多人的報告是把代碼從頭貼到尾這是最浪費時間也最不討好的做法。報告要回答的是“為什么這么做”不是“代碼長什么樣”。4.1 報告的六段式結構與每個章節(jié)的篇幅配比我一般按六段來組織總頁數(shù)控制在 20~30 頁之間太短顯單薄太長老師沒耐心看。章節(jié)核心內容篇幅建議封面與任務描述題目名稱、原始需求摘錄1 頁需求分析功能清單、數(shù)據(jù)規(guī)模假設、邊界條件1~2 頁概要設計存儲結構選型、模塊劃分、函數(shù)接口表2~3 頁詳細設計核心算法流程、代碼摘錄、復雜度分析3~5 頁測試與結果測試用例表、運行截圖2~3 頁總結與附錄遇到的問題、解決過程、主要源碼1~2 頁正文需求分析別看名字高大上其實就是把你做的東西用大白話說清楚輸入是什么、輸出是什么、哪些情況要考慮。比如校園導航系統(tǒng)需求分析里要寫明“支持 5 個景點間的最短路徑查詢道路是無向帶權邊輸入非法編號時提示錯誤且不退出”。邊界條件這一小節(jié)是拉開差距的地方能寫“文件不存在時提示并退出”的人說明真考慮過運行環(huán)境而不只是把樣例跑通。概要設計里的模塊劃分要和你代碼里的函數(shù)一一對應。最忌諱的是報告畫了一張模塊圖代碼里卻是一個 300 行的 main 函數(shù)。你哪怕只是把上一章的類方法列個表寫上函數(shù)名、參數(shù)、返回值、作用評閱老師就知道你有設計意識了。4.2 復雜度分析和測試數(shù)據(jù)評閱人最看重的兩頁紙詳細設計里最值錢的是兩頁紙一頁是復雜度分析一頁是測試用例表。復雜度分析不是抄一句話“時間復雜度為 O(n2)”就完事而要寫出“為什么是這個復雜度”。以校園導航為例Dijkstra 堆優(yōu)化的分析邏輯是每個頂點入隊出隊各一次為 O(V)每次出隊帶 logV每條邊在松弛時被檢查一次為 O(E)總復雜度 O((VE)logV)空間上鄰接表存邊 O(E)dist 和 prev 各 O(V)。這一段寫清楚答辯時老師基本不會再刁難。測試用例表建議做成“編號、操作、輸入、預期輸出、實測輸出”五列覆蓋正常路徑和異常輸入編號操作輸入預期輸出實測T01加載數(shù)據(jù)data.txt5 頂點 6 邊菜單正常瀏覽全圖完整通過T02最短路徑起點 0終點 40 - 3 - 4長度 350通過T03不可達路徑臨時移除邊后查詢打印“沒有通路”通過T04非法編號起點 99提示錯誤不崩潰通過這里有個真實的評分心理老師翻報告時T01、T02 都通過不稀奇T03、T04 這種異常用例能一眼看出你做了邊界測試。哪怕你實際沒測也要把這種用例設計出來花五分鐘把代碼跑一遍確認輸出比啥都不寫強得多。4.3 圖表、截圖與參考文獻的組織方式含查重注意圖表方面模塊圖、流程圖用 Visio 或 ProcessOn 畫別用代碼截圖代替流程圖。截圖的規(guī)范是窗口標題欄要露出來終端窗口別拉伸到變形運行結果中文字體保持一致。有一個容易被忽略的點截圖里的路徑、日期要和你的報告其他部分一致別周三截一張、周五截一張輸入輸出對不上老師一眼就看出來。參考文獻不用列多兩三本足夠比如嚴蔚敏的《數(shù)據(jù)結構C 語言版》以及你用的語言對應的算法書像《數(shù)據(jù)結構與算法分析》的 Java 或 C 描述版。注意別把網(wǎng)上的教程鏈接列成參考文獻格式會很難看如果確實參考了某個博客可以在總結里提一句不要寫進參考文獻。查重這塊要特別提醒現(xiàn)在課程設計報告和代碼都會過查重系統(tǒng)報告文字查重主要盯需求分析、概要設計這些“套話高發(fā)區(qū)”。解決辦法是別背模板用自己的話寫比如你實際遇到的亂碼問題、路徑問題寫進心得里既真實又查不到。代碼查重是按行比較的網(wǎng)上公開源碼、GitHub 上的同題項目改變量名刪注釋能降一檔重復率但最穩(wěn)的是自己照思路重寫。還有一個習慣性動作如果你的代碼要推到碼云、GitHub 做版本管理倉庫務必設成私有公開倉庫不僅可能被下一屆同學原樣抄走答辯老師搜到同名題目后你們倆都得倒霉。5. 常見問題與避坑從編譯報錯到答辯翻車的四條真實記錄課程設計翻車的場景高度集中我把最常見的四條按“現(xiàn)象、原因、解決”寫清楚。每一條都是我在不同機器、不同同學那里見過不止一次的。5.1 代碼在別人機器上跑不起來運行庫、工作目錄與漏文件現(xiàn)象在自己電腦上編譯運行都正常把 exe 復制到 U 盤帶去機房或老師的電腦上雙擊后黑框一閃就沒了或者彈窗提示“由于找不到 msvcp140.dll 無法繼續(xù)執(zhí)行代碼”。原因分兩種。第一種是 Debug 模式編譯出的 exe 依賴開發(fā)機的 VC 運行庫目標機器沒裝就會報 msvcp140.dll 缺失第二種更隱蔽——程序本來就是從 data.txt 讀數(shù)據(jù)但 exe 在 U 盤里data.txt 還在桌面上加載失敗后代碼直接 return 1黑框一閃而過老師只看到“程序打不開”。解決提交前用 Release 模式重新編譯有條件就靜態(tài)鏈接運行庫把 exe 和 data.txt、README 放在同一個文件夾里打包換一臺沒裝開發(fā)環(huán)境的機器雙擊驗證一次。代碼里加載文件失敗時別光 cout 一句就 return先輸出“當前工作目錄是 xxx”這行調試信息能瞬間定位路徑問題確認后再刪掉。5.2 中文亂碼與 scanf_sDev-C 和 Visual Studio 的差異現(xiàn)象同樣的代碼在 Dev-C 里好好的拿到 Visual Studio 里編譯報警告甚至報錯運行后菜單里的中文全變成亂碼。原因兩個編譯器默認編碼不同Dev-C 老版本默認按 GBK 保存和讀取源文件VS 默認 UTF-8另外 scanf_s 是 VS 特有的安全版本標準 C 里沒有在 Dev-C 里根本編譯不過。解決統(tǒng)一把源文件另存為 UTF-8 編碼代碼里盡量用cin/cout代替scanf/printf少碰平臺私有函數(shù)。如果學校要求必須用 VS用 scanf 的地方可以在文件頂部加一句#define _CRT_SECURE_NO_WARNINGS屏蔽安全警告但這不是好習慣我一般直接改成讀文件流。菜單文案別用生僻字普通漢字在 UTF-8 和 GBK 下都能正常顯示的就問題不大。5.3 報告和代碼查重暴雷公開源碼是最容易踩的坑現(xiàn)象提交后查重報告相似率 60% 以上被老師約談或者代碼部分被標紅理由是“與某公開項目高度相似”。原因大概率是直接搬了 CSDN、GitHub 上的同題源碼變量名和函數(shù)結構都沒改報告則是套用了下載的課程設計模板需求分析整段照抄。解決代碼要自己重寫哪怕思路參考公開源碼也要換一種組織方式。拿校園導航為例別人用鄰接矩陣你就用鄰接表別人用全局函數(shù)你就定義類別人一次讀入所有數(shù)據(jù)你就改成逐行流式讀取。這些改動不是敷衍查重而是讓代碼真正變成你自己的。報告的心得部分寫真實調試過程比如“Dev-C 下中文輸出亂碼最后通過把源文件保存為 UTF-8 解決”這種內容既查重查不到答辯時也是你的真實素材。5.4 答辯三連問為什么這個結構、復雜度多少、數(shù)據(jù)量大了會怎樣現(xiàn)象答辯時演示順利但老師問“為什么用鄰接表不用鄰接矩陣”時只回答“因為上課講過”問“復雜度多少”答不上來追問“頂點從 50 變成 5000 會怎樣”直接沉默。原因代碼是調通甚至背下來的但設計過程的每個決策沒有準備理由。數(shù)據(jù)結構課程設計答辯問來問去就是這三個方向——選型理由、復雜度、擴展性。解決提前按這三問準備應答。選型理由要說對比鄰接矩陣適合稠密圖且實現(xiàn)簡單但空間 O(V2)頂點過千就浪費鄰接表空間 O(VE)適合校園導航這種稀疏圖。復雜度要背熟并且能解釋每個字母代表什么。擴展性問題給出思路即可頂點數(shù)增大后Dijkstra 堆優(yōu)化仍然能跑但若圖變成稠密圖鄰接矩陣 樸素 Dijkstra 在某些場景反而更快這是一道開放題你說出權衡就過關。答辯前把這三問的答案寫在報告第一頁背面進門前掃一眼。6. 答辯前一天的驗證方法一份自測清單把分數(shù)穩(wěn)住答辯前別再改功能改多錯多。按下面這份清單做一次系統(tǒng)驗證每項都實際操作一遍不打勾不進場。檢查項怎么查通過標準干凈環(huán)境可編譯關掉 IDE 重新打開工程全部重新生成無 errorwarning 能解釋文件打包完整exe、data.txt、源碼、報告放同一文件夾另一臺機器雙擊能進入菜單核心功能演示按演示腳本走一遍瀏覽、查路徑、退出輸出路徑和長度正確邊界輸入輸入不存在的編號、超范圍負數(shù)有提示不崩潰異常輸入把 data.txt 改名后運行打印錯誤信息并優(yōu)雅退出代碼與報告一致對照報告摘錄的代碼和工程源碼函數(shù)名、輸出格式完全一致最后一條是最容易忽略的答辯老師會翻報告里的代碼摘錄再翻你工程里的源碼如果函數(shù)名對不上、輸出格式不一樣印象分會掉很多。演示腳本我建議固定成三幕先瀏覽全圖讓畫面停留在“打印鄰接表”的終端輸出上然后查一條從起點到終點有繞行的路徑輸出四五個節(jié)點展示算法真實在找路最后故意輸一個錯誤編號展示健壯性。全程兩分鐘不要現(xiàn)場敲代碼不要現(xiàn)場編譯那些是扣分風險點而不是加分點。我吃過一次虧那年答辯演示我把 data.txt 放在了桌面程序在 U 盤里雙擊后加載失敗直接退出老師看到的就是“程序打不開”解釋半天也沒用。那次之后我養(yǎng)成一個習慣所有課程設計在提交前一晚一定在 U 盤里用 Release 版完整走一遍演示路徑從頭到尾不碰 IDE。這段血淚經(jīng)驗送給你的話就是“演示環(huán)境和你寫代碼的環(huán)境不一樣永遠以目標環(huán)境為準”。希望幫到你。本文還有配套的精品資源點擊獲取