C

故事是這樣子的， 很早以前我寫過一篇介紹 python ctypes 的文章，已經是 7 年前的文章了， 大約在去年左右，曾經發現一個生猛的用法但那時沒記下來，最近又用到了結果又要花時間找設定，這篇就再次記錄一下。

故事是這樣子的，小弟在公司工作內容，要維護公司產品核心的engine，要維護當然會需要把程式碼從版本控制裡簽出來， 修改、編譯後測試修正有沒有問題，而編譯一直以來都非常花時間。
本文介紹的 ccache 是 compiler cache 的簡稱，會在編譯時存下檔案內容的 hash 與編譯結果，在未來如果有相同的檔案要編譯的時候，就不用再次呼叫 gcc/g++ 進行耗時的編譯，只要把存下的 object 檔從 cache 裡面抓出來就行了。

故事是這個樣子的，寫 C/C++ 必定會遇到的就是每個檔案開頭的 #include，這可以帶入其他人寫好的程式碼，最後連結的時候再連結函式庫完成整個程式。
不過大家都知道，程式不是寫完就算了，是會長大跟更新，這時候 include 就會慢慢過時，可能本來需要的 include 現在不需要了，但通常我們不會意識到這點。
另外，在一些 project 上，會出現所謂的組合的標頭檔，例如 Qt 會有 QtGui 標頭檔，內含幾乎所有 Qt 元件的標頭， 不管需要什麼 Qt Widget 只要有 QtGui 都能搞定，但問題就是 include 一個標頭檔會帶進標頭檔裡所有程式碼，巨大的標頭檔如 QtGui 會顯著拖慢編譯速度； 如果只是一兩個檔案當然沒什麼，但在大 project 上，例如我之前改的 qucs ， 我把裡面的 QtGui 全部換成專屬的 Qt Widget 之後，單核心編譯時間從原本的344秒加速到245秒，提速 29 %。

故事是這樣子的，小弟在公司裡面，主要是負責維護一個沒人在用的產品，遠觀來說這個產品滿複雜的，內建兩種不同的演算法實作，為的是要應對不同的狀況，有些狀況用第一種演算法比較快，有些用第二種。
那故事是這樣子的，我們的程式裡面有一個函式會在每筆資料結束之後，用上筆資料的結果來判斷下一次要選哪個演算法， 問題是這個函式目前是直接寫在整個引擎的 C code 裡面，於是如果想要改變一下判斷的標準……sorry 重新 build， 雖然公司弄了套分散編譯可以編很快但還是要幾分鐘。
上星期自己試了一下，成功把 Lua 編到公司的 code 裡面，就能把判斷邏輯寫在 Lua script 裡面，要改判斷標準只要改 Lua 就可以了； 我一般聽到會這樣用的是遊戲公司，因為遊戲一樣涉及大量的邏輯判斷，例如血要扣多少之類的，而遊戲又會大量的去變動這些參數， 使得彈性變得非常重要，總不能要改參數就把整個遊戲引擎全部重建構一次…… 說是這麼說我也不曾證實哪家公司真的這麼做就是，如果我的讀者真的是這樣搞的麻煩留個言讓我知道一下。

在寫Makefile 的時候，一般的規則是這樣的：

Target: Dependency
    Command

Makefile文件稱 command 為 recipe，不過我這邊就寫command。
如果是C 程式，通常也會把 header 檔寫在 dependency 內，否則 header 檔改了結果程式沒有重新編譯就奇怪了，如果每次改了header 都要 make -B 也不是辦法。

故事是這樣子的，最近小弟接觸一項工作，主要是開發一套C 的API，實作大程式底層的介面， 以前只有改過別人的介面，這次自己從頭到尾把介面建起來，git repository 提交100多個commit，說實在蠻有成就感的。
寫Project的過程中也發現自己對測試的經驗實在不夠，本來想說該把unit test set 建起來然後做個 regression test， 結果unit test 寫一寫最後都變成behavior test 了，啊啊啊啊我根本不會寫測試啊，測試好難QQQQ

其實這是整理在BBS上的舊文，想說就把它轉到這裡來，是記錄如何在程式裡面加上顏色的控制，如果熟BBS的人應該很熟悉， 似乎是一個公訂的標準上色方式，大家參考參考，也許可以讓你的程式增添不少色彩，能不能為人生上色就說不準了。

正規表示式是個強大的工具，定義了明確的定串比對規則，來幫助使用者把梳字串，在很多程式都有支援，如 Linux shell 的grep, awk, sed，vim的搜尋取代功能等， C語言的scanf其實也有支援，可惜正規表示法規則甚多，一時之間難以記全。

這篇主要記錄正規表示法的規則，整理自"Practical Programming in Tcl and Tk"第十一章，給自己做個參考：

最近寫了很多檔案處理的程式，涉及許多字串中，包含數字符號、跳行的內容，不斷的看許多scanf的相關文件，把它整理在這裡，供大家參考。