2013年11月3日 星期日

gj: 閱讀 C/C++ 原始碼的好幫手

兩年前剛開始接觸大型 C++ 專案時, 研究了一下尋找 symbol 相關位置的工具。最後依自己的需求, 做了一個小工具 gj。經歷了近兩年的使用和改進, gj 已成為我工作環境裡不可或缺的一塊了。

gj 的特點是:

  • 建立索引和找尋 symbol 的時間極短, 沾 ID Utils 的光, 不費任何力氣就有這樣的成果。
  • 盡可能不要漏掉可能的相關檔案, 並提供互動過濾的機制, 方便找出目標。
  • 和 vim 整合一起使用。

這裡有 gj demo 的畫面。

雖說目前已可應付我自己的九成需求, 還是有不少可改進的地方, 只是用到的情境較少就懶得補了。大家若有興趣使用, 歡迎提供建議。愈多人有需求, 愈有動力來改。或是用過 gj 後, 覺得有其它和 vim 整合得好工具, 也歡迎推薦。

6 則留言:

  1. 有試過 unite.vim + unite-grep + unite-tag 嗎 ?

    回覆刪除
  2. 之前沒試過, 看起來頗多功能的, unite-grep 也有內文搜尋 + 檔案路徑的過濾機制, 果然大家的需求都差不多 http://vimeo.com/24700977

    改天來試用看看, 謝啦

    回覆刪除
  3. 試用gj感覺不錯, 目前我也是用vim trace code ,
    但是在有個困搞就trace過程很容易搞亂trace 流程, 目前我只用紙筆紀錄
    不知道是否有什麼有效方法紀錄起來
    謝謝

    回覆刪除
  4. 這問題也困擾著我, 嘗試過紙筆和 vim 後, 目前我是用 vim 另開文字檔記錄。

    主要的原因是方便複製貼上關鍵的函式碼或 backtrace。比方說針對觀察的 call flow 有五層函式一路 call 下去, 我會對這五個函式分別取我有興趣的程式碼, 貼到文字檔裡, 方便我釐清這個 call flow 做了那些事, 為什麼要做這些事

    同時, 我會逐步記錄「我想解決的是什麼問題」, 「已知的事實為何」, 「由已知的事實得出的推論 = 接下來要驗證的目標」, 「目前的疑問 (例如相斥的推論)」。

    不過用 vim 的缺點就是不能像紙筆那樣天馬行空的畫圖, 但考量到要複製或打的字太多了, 目前還是以 vim 編文字檔為主。還在摸索有沒有更方便的作法

    回覆刪除
    回覆
    1. 有考慮graphviz嗎?
      用寫小程式方式來畫圖
      在一開始用
      f1[label="function1()"];
      f2[label="function2()"];
      就可以把一長串的函數名稱縮寫
      接下來用f1->f2就可以在函數間自由連接
      也不用管圖片擺放位置,他會自動幫你調好

      刪除
  5. 之前有用過 graphviz 畫 data flow, 滿方便的。印象中有看過別人作的工具, 用 graphviz 產生 call flow (好像是只能處理 C)。我自己的感覺是這類工具會產生太多資訊, 圖太大不容易讀, 使用經驗不多, 不太有參考性就是了。目前習慣針對有興趣的地方加 log, 配合 gdb 看 backtrace 或直接 log backtrace, 還能應付目前遇到的情況。

    回覆刪除

在 Fedora 下裝 id-utils

Fedora 似乎因為執行檔撞名,而沒有提供 id-utils 的套件 ,但這是使用 gj 的必要套件,只好自己編。從官網抓好 tarball ,解開來編譯 (./configure && make)就是了。 但編譯後會遇到錯誤: ./stdio.h:10...