如何在編程中更好地踩坑與進步?

刷知乎這麼久了第一次提問,這個問題範圍可能有些寬泛,還請大家見諒。

自從14年弄明白遞歸,知道 @vczh 輪子哥之後,強行按照輪子哥的路子走,寫過基於 scan-line 的 full screen software renderer,勉強入了圖形的門,也勉強走了趟虎書(不包含SSA、寄存器分配以及函數式的相關章節,沒寫過這幾章的相關代碼),多少算是能擼一個玩具級的解釋/編譯器,也造過一些其他輪子,比如可視化編程環境之類。但是最近一段時期發現自己雖然踩坑不少,進步反而慢下來了。而且回顧自己之前寫的那些代碼,雖然能work,但質量普遍不高,屬於踩坑居多,修修補補,而且最近越發不敢用C++了……會做跟能做好真是兩回事情…… :

所以我的主要問題有兩個,以及附帶其他兩三個小問題。

主要問題:

1. 如何更好地踩坑?個人項目踩坑的時候如何保證代碼質量?是優先保證完整度,暫時打補丁,積累到一定程度的時候再推倒重來還是有更好的方法?企業項目又是如何進行的?

2. 老生常談的如何更好地使用C++,或者說學習哪些編程範式有助於更好地使用C++。其實個人感覺這個問題更多體現在如何採用更加現代的編程方式去寫程序,當然,我C++水平一般,不敢妄言太多。

次要問題:

1. 這幾天在搞一個 tile-based 的 software renderer。當然是受到 @空明流轉 的 Salvia 的啟發,自覺現在水平可以嘗試弄個弱化版的出來。目前採用 hierarchy edge test 進行光柵化的時候三角形重心插值值出現了問題,如下圖:

仿射紋理:

透視紋理:

而在之前寫過的 full screen scan-line 的 renderer 裡面投影紋理是沒有出現這種情況的:

1/z插值過程應該是沒有問題的,導致透視紋理出現這種情況是因為浮點精度或者其他原因?是否有相關的坑我沒有踩到?

2. 由於之前沒有進行過寄存器分配的實現,所以在看線性掃描寄存器分配的時候不知道自己的理解是否正確,不知道是否有大佬願意指點一下。總結在[這裡的最後一部分]。


這個很簡單,去看人家的best practice,然後反著做,吃點屎,馬上就明白了。而且題主你的要求有問題。踩了坑當然是因為代碼質量不行啊,怎麼能在踩坑的時候保持代碼質量呢?這種問題多重構就好了,不要怕重構和重寫。進步快慢也不看你到底寫了多少個exe。

還有那個貼圖的問題,自己人肉一下公式,看看你三角形左下切還是右下切,會不會改變你一個點最後映射到貼圖的坐標(逃


如果是覺得自己代碼弱質量不高,那可以看我在 b 站直播的視頻,你的話,大概要看 1 到 15 期

對你來說,這是最快最划算的方法,不要糾結語言,代碼本就是語言無關的

地址在我名字下方

另,誰能幫我在評論區發個之前講這個的知乎鏈接?


就是多踩坑吧,每次趟完一個大坑,都會有自己水平大進的錯覺,然後再撲入下一個坑。

自己從頭開始寫不好控制質量,可以找點名校的課,在人家start code的基礎上寫寫lab/project,質量都挺高,踩踩坑,覺得幫助也挺大的。


個人感覺踩坑和進步是在一個體系里的。踩坑-》加班-》搞定-》進步。想進步的更快就要更多的踩坑和進步。好像沒啥更好的踩坑姿勢。


準備前十年,在泥潭中前行。

後十年,做各種輔助工具,幫助後人舒服的在裡面行走。


推薦閱讀:

全局靜態變數,互斥信號量等在內存中是怎麼處理?
shift reduce,預測分析,遞歸下降分析(這是解析方法)和LL(K) LR(K) SLR以LALR的關係?
C++ template 為什麼不能推導返回值類型?
什麼編譯器優化技術可以把FP語言里的sum [1..n]的效率優化到C語言的水平?
即時編譯器與解釋器的區別?

TAG:C | 編譯原理 | 計算機圖形學 |