→ kiedveian:同好，玩碧軌+cppgm XD，不過我在寫pa3之前就一口氣破了 07/09 23:16
推 ck574b027:其實我覺得這系列文標題要分一下了，一整串回文後人也 07/10 00:16
→ ck574b027:不知道要去哪裡找線索。 07/10 00:16
剛剛過了PA5。
看見了一切人民喜樂見聞，PA3-5 deadline延期一個禮拜的消息之後
上禮拜六帶著暢快的身心打了Steam買來的Tomb Raider
自從參加某CPPGM界王拳修練，好久沒這麼痛快的打電動
某碧之軌跡最終章被我從PA1拖到現在還沒破完囧
今天才把PA5做完
那些能一個禮拜做一題
或是能在別人寫PA2、PA3就已經做到PA6的人真的是不同次元的怪物
言歸正傳，雖然高手們都過了
不過搞不好有下一梯次的人會需要線索，所以小弟還是提出一點淺薄心得
錯誤之處、設計不良之處傷到高手的眼睛請包涵了。
1. 這次最困難的部分感覺是#line和__LINE__的實作
測資會包含類似
#line \
100
/*
This is a very happy comment
you __LINE__ calculation is screwed
*/
__LINE__
這種測試，設計時務必注意comment、line splicing等的影響，一開始就想好怎麼做
小弟是文字讀進來時順便算\n出現在哪個位置（稱為\n陣列）
然後產生token的時候看看現在在哪兩個\n之間
但是\n陣列的計算會隨著line splicing，comment matching把buffer內的東西換掉而失
真
小弟在lexor內部處理line splicing和comment的地方對\n陣列內的值做正確修正
至少是混過所有測資了（煙）
2. 次難一點是conditional inclusion。官方Design note建議的Stack方法可行。
3. 再次難小弟覺得是#include，小弟所有的token都增加了檔名、行號的資料。所以
include進來的Token不會跟主檔的Token搞混。用Stack判斷if section的進出也因此不會
出錯。
4. 其他#error，#pragma，non-directive等相對就還好。
目前小弟面臨的挑戰：
1). PA6：好棒的 LL(1) parser generator，不寫嗎？
2). Code隨著每題的進展越來越龐大，也越來越多Hack。因為支援更多東西，加更多資料
結構做更多檢查導致效能變差以外（效能差官方好遠啊）。程式的維護性更已經降低到難
以忍受的地步。也許該趁我還記得我當初在寫些甚麼的時候refactor一下。
謝謝收看Q_Q
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 118.233.183.133
※ 編輯: d8888 來自: 118.233.183.133 (07/09 22:20)