寒假做業3

時間 2019-11-30

標籤寒假简体版

原文原文鏈接

各文件	調試時長	代碼行數	調試的bug數
main.cpp	10-25h	249行	15-29個
elevator.h	-	21行	2個
elevator.cpp	-	16行	0個
control.h	-	21行	0個
control.cpp	-	26行	0個
總計	10-25h	333行	17-29個

進擊的優化

對非法輸入進行警告退出處理
把順風車模式改爲最近接客模式，即若是要去的地方比接下一個請求的來得遠，選擇接下一個
更好優化的思考：加權移動：不能讓電梯上一堆人下去接一我的
更好優化的反思考：加權移動致使了可能錯過更多下面要去上面的人
更加好的想法：對歷史數據進行估計，判斷哪一種狀況更多，基於歷史進行選擇

1

開了新的腦洞
電梯分爲停下和運行兩個狀態
按裏面的按鈕和外面的按鈕沒有區別
電梯向按着按鈕的樓層出發
到了樓層就更新狀態
接客和載客
把狀態更新

2

理了一下
先響應最近的乘客，再響應路途上的乘客

3

更新的腦洞
維護一個請求表，直接往離當前請求最近的樓層移

4

寫完了，嘗試了一些失敗的想法，上面的1，2，3能夠不看了，講講最新的狀況git

思路（能夠看代碼，代碼不難看）
使用了面向對象的方法，將電梯和控制面板對象化，用到了以前筆記裏的構造函數等等
電梯：能夠一層一層上下移動，反饋在第幾層，簡單地反映電梯裏有幾我的，上下客，無人即爲空載
控制面板：記錄請求的人在哪讓電梯去接，請求的樓層在哪讓電梯去送
使用函數追蹤當前電梯離那個請求樓層最近即向哪層移動
許多未使用函數爲擴展留下空間github

文檔
上次的文檔仍是能夠用的，代碼內加了更多的註釋算法

問題
算法不是最優，程序還有一點bug
迴避了對象的消息傳遞segmentfault

樣例

1

輸入5個1 2 3檢驗同時載客+簡單狀況
輸出爲
4時，停靠在3樓
4時，停靠在3樓
4時，停靠在3樓
4時，停靠在3樓
4時，停靠在3樓
15
符合預期編輯器

2

輸入
1 1 2
2 2 3
3 3 4
4 4 5
5 5 6
模擬一樓同時上下客狀況
輸出
3時，停靠在2樓
5時，停靠在3樓
7時，停靠在4樓
9時，停靠在5樓
11時，停靠在6樓
20
符合預期函數

3

輸入
1 1 0
10 5 1
50 0 3
70 0 8
100 1 9
模擬反覆上下樓
輸出
~~程序卡死代表有問題~~
11時，停靠在10樓
22時，停靠在1樓
67時，停靠在3樓
80時，停靠在8樓
122時，停靠在9樓
71
符合預期
是沒有對0當前位置轉換成10處理形成的測試

4

輸入
1 1 0
2 1 0
3 1 0
4 1 0
5 1 0
模擬下樓載客狀況
輸出
15時，停靠在10樓
15時，停靠在10樓
15時，停靠在10樓
15時，停靠在10樓
15時，停靠在10樓
60
符合預期優化

5

輸入
1 5 1
6 1 3
7 6 2
10 5 9
11 3 2
模擬小規模混亂數據
輸出
10時，停靠在1樓
13時，停靠在3樓
24時，停靠在2樓
32時，停靠在9樓
24時，停靠在2樓
68
符合預期調試

6

輸入
1 -5 1
6 1 3
7 6 2
10 5 9
11 3 2
輸出
輸入不合法
符合預期

log截圖（ps:運行截圖不放了，上面的結果拿GitHub裏我程序隨意復現，主要是截圖太佔版面）

一些額外的BB
這是我寫的時間最長的一次代碼，中途一度想把這個丟了再寫一個，仍是沒有徹底放棄，終於寫完了
文件讀寫使用很習慣的freopen("*.*","way",mode),須要'stdio.h'(c)或cstdio(c++)頭文件，「.」是須要讀寫的文件名（和編譯後可執行文件同目錄下），「way」是「w」或「r」表示write寫入或者read讀取，「mode」是「stdin」或「stdout」和「read」，「write」互相對應
Visual Studio Code是一個不錯的編輯器，可是要調教成一個好的IDE還有不少步驟要作
源碼裏額外的cout輸出是bug調試用途，能夠測試完整的上下樓流程，好比電梯移動到幾樓，接進幾我的，幾我的下電梯等等
本代碼去掉vsc下注釋經Visual Studio Code+clang編譯生成代碼，若是完整IDE請把多個cpp鏈接編譯
commit規範由最先的混亂到如今的基本規範主要是從單看廖雪峯git到看了commit規範指南以後的轉變
若有紕漏或建議，請各位不吝指教