顯顯技術報告

在寫 unit testing 時偶爾會不小心漏掉了一些 case 導致測試不完整，coverage report 可以幫我們做初步的檢查，確保測試程式有一定程度的品質，還可以順便抓出沒有用到的 code gcc --coverage 為了產生分析 coverage 必要的資料，我們必須在 compiler 時加上 --coverage 的參數，才能夠在程式執行時，得知每行程式碼是否有被跑到，在 link 時也要加上 --coverage 。重要的是還要將最佳化關掉，避免最佳化影響統計的結果，可以參考 CMakeLists.txt ，我使用的 gcc 版本為 7.4.0。 SET (GCC_COVERAGE_COMPILE_FLAGS "-g -O0 --coverage" ) SET (GCC_COVERAGE_LINK_FLAGS "--coverage" ) SET (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${GCC_COVERAGE_COMPILE_FLAGS}" ) SET (CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${GCC_COVERAGE_LINK_FLAGS}" ) 透過這樣的參數來 compile 後，可以發現所有 *.o 的旁邊都多出了 *.gcno 的檔案，可以想成他記錄了每一行的程式碼，之後要用來比對是否有哪一行沒有被執行到 範例 完整的 code 一樣放在 github 這次的範例包含了一個 TestClass 在 libarary 中，裡面有 private function 和會被測試到與不會被測試到的 function 各一個 void TestClass::TestedFunction( bool cond1, bool cond2) const { PrivateFunction(cond1, cond2); } void TestClass::UntestedFunction() const { PrivateFunction( false , false ); } void Tes

動機 目前大部份的程式都是用 C++ 來實作，不過有時候會有使用 python 比較方便的時候（例如做 API 的整合測試），這時候可能會在 python 實作一些和 C++ unit test 中一樣的邏輯，但直接重寫一次很容易在日後修改時發生行為不一致的狀況，因此讓 python 能夠直接使用 C++ 的 library 就是比較好的選擇 解法選擇 Boost.Python Python ctypes library 除非本來的 project 就有使用到 boost，否則要將 Boost.Python compile 起來是需要花一些工夫的，這邊會比較建議使用 ctypes library，但是 ctypes 只能夠支援 C 的 interface，這篇文章會教你如何將 C++ 的 class 透過 wrapper 的方法轉到 python 上，這方法是幾個月前從 stackoverflow 上看到的，我覺得比較容易讓 python 和 C++ 上對該 class 的使用體驗一致，分享給大家 Example 完整的 範例程式碼 都有放在 github 上 程式解說 每個檔案的說明如下： library.h library.cpp: 實作 class main.cpp: 使用 library.cpp 提供的 class 做 demo library-python.cpp: 提供介面給 ctypes library.py: 透過 ctype 提供 python 版本的 class ctypes-demo.py: 如同 main.cpp，使用 library.py 提供的 class 由於 cytpes 只支援 C 的介面，因此我們需要將 class 的每個操作都寫成 function 的形式(包括 constructor、destructor)，並透過指標來 access member，這邊列出一部份的 code TestClass* TestClass_new() { return new TestClass(); } int TestClass_member(TestClass* ptr) { return ptr->member(); } 接著在 python 端，就可以透過

動機 在好幾年前寫過幾篇技術 blog 文章，雖然當時只是希望分享給同學看，最後竟然也有一些人透過 google search 找到，也有在留言區討論問題。但畢業後就沒有再動過了，最近又想把寫 blog 的習慣重新撿回來。 內容的話目前希望有自己 side project 相關的隨意筆記，或是讀書後的詳細心得 (常常覺得書中講得不夠詳細，或是範例不夠完整) 選擇 blog 平台 最近 markdown 語法開始進入公司內部各種文件的撰寫，自然我也想使用 markdown 做為寫 blog 的語言。我喜歡 markdown 可以將內容與 style 完全切開的設計，就好比使用純 html + css 來製作網頁一樣，markdown 主攻內容，至於最後的呈現部份可以另外找到各種外掛幫你 render 成想要的樣子，這邊就列出了我找平台的條件： 如果能自己架是最好，線上服務的話要有信心不會倒 能夠原生或使用 plugin 來支援 markdown 要有留言系統 可以自己調整 style 技術 blog 永遠少不了的 code syntax highlight 接著上網陸陸續續找了幾種解法： Wordpress 這個方法一開始在我心中就被排除了，原因只是個人覺得 wordpress 功能太過強大，幾年前有架起來一個 wordpress 站，常常會為了一個 plugin 搞半天，處理 plugin 版本相容問題，plugin 之間相容問題，後台的設計讓功能不是非常好找，拿來作為個人網站比較合適，以純 blog 需求來看有點殺雞用牛刀的感覺 Medium 和 wordpress 一樣原生不支援 markdown，而且無法自己換 style，所以不採用 Jekyll 搭配 git 來寫 blog，聽起來很工程師很酷XD，所以有實際跑起來測一下，遇到了幾個問題最後放棄了： Jekyll 要搭配 ruby 使用，雖然我在 linux 與 windows 的電腦都有成功安裝了，但換到新的電腦就要重新安裝一次 由於是靜態網頁產生器，如果要做留言的話要另外處理，這時又會出現選留言平台的問題…(線上怕倒，自己架花時間，或是要錢) render 有點迷樣，例如有三個 page，其中一個 page 沒有寫 title 屬