這是一位網友的問題,原問題見http://www.ptt.cc/bbs/C_and_CPP/M.1351841869.A.BAF.html。本部落格之前也稍微碰過這個主題,不過之前的重點在於腦筋急轉彎式的模擬 __VA_ARGS__ 功能,實用性是另一回事。

在開始討論各種作法可行性之前,這裡先宣導一項原則:應該要讓正常輸出與非常態輸出分流,更精確的說,給使用者看的輸出應該要和給開發者看的輸出分流。例如使用 stdout 作為正常輸出時,就不應該也用 stdout 作為非常態輸出,而是改用 stderr 或檔案。實戰中非常態輸出的 sink 很多樣,這裡就不多說了。即使不想多花心力去設計非常態輸出機制,使用基本的 stderr 並不會比用 stdout 多費功夫,好處卻是立即可見,可謂有利而無害。

回到原問題上。最常見的 debug code 不外乎吐出一堆程式內部狀態的資訊,以下我用 dprintf 來表示一個用法和 printf 完全相同、但流向不同管道的函數,不一定會和讀者手邊編譯器所提供的 dprintf 相同。原問題所使用的策略,亦即用 macro 製造註解來吃掉 debug code ,到底可不可行呢?

#define dprintf //

dprintf(...whatever...);

依照標準的 C++ preprocessor 轉換流程,處理註解的時間點早於 macro 展開,所以 // 會先被視為對這一行的註解而忽略掉,這相當於把 dprintf 定義成空字串,原本的參數列則會被留下來變成一組用小括號括起來的逗號運算式。很有趣的是,當這組逗號運算式沒有副作用的時候,使出這招的人還會誤以為自己的把戲成功了。有人可能會說,無論如何輸出都被消掉了,那麼也算是達到目的了吧。我的看法是,如果撰寫者嚴格遵守 debug code 不可有副作用的法則,這倒也不失為一個方法,問題在於寫出這樣程式碼的人八成沒意識到這點,而且遇到像 cerr、clog 這種形式的輸出就沒轍了。

還有一些方法試圖利用 ## 連接字串的方式製造 //,不過這些做法只對部分編譯器有效(例如 VC)。事實上標準的 C++ preprocessor 轉換規則已經否定這種做法(一是處理註解的時間點、二是//不是合法的 preprocessing token),所以可以預期拒絕的編譯器應該會比通過的編譯器還要多。總而言之,在標準 C++ 下沒有辦法用 macro 製造註解。這也意味著,不存在既能融入程式碼而且通用於各種陳述形式的方法。所以呢,原問題的發問者歪打正著,反而是網友提供的意見不可行。

接下來討論一些正常處理這類問題的手法。對於函數形式的運算式而言,最直接的方法還是用 macro 包裝。例如:

#ifdef NDEBUG
#   define DFUNC(a, b, c)   ((void) 0)
#   define DPRINTF(...)     ((void) 0)
#else
#   define DFUNC(a, b, c)   dfunc(a, b, c)
#   define DPRINTF(...)     dprintf(__VA_ARGS__)
#endif

比較大的麻煩是舊一點的編譯器可能不支援 __VA_ARGS__。而遇到 stream 式的輸出格式時寫起來怪彆扭的:

#define DOUT(expr) cerr << expr;

DOUT( "message " << 15 );      // shift a string literal??

如果追求較高相容性的話,另一個很常用的方法是將運算式放到不會被執行的路徑上,這類的做法不僅適用於函數,也適用於大部分的運算式。候選的做法可能有:

#define DPRINTF  0 && dprintf               // bad
#define DPRINTF  if (0) dprintf             // bad
#define DPRINTF  if (1) {} else dprintf
#define DPRINTF  (1)? (void) 0 : (void) dprintf

邏輯運算具有短路性質,而且優先順序還算低,看起來似乎適用。主要的問題在於,邏輯運算需要兩個運算元都可以轉成布林值,而目標運算式卻可能具有各種型態,事實上有些 dprintf 實作的回傳型態就是void,因此邏輯運算被淘汰。單獨的 if 若是放在風格不良的巢狀 if-else 當中,很可能會意外和別人的 else 結合,所以放在 else 路徑上才不容易被誤用。我所見過的案例大都採用三元運算子。使用三元運算有一個必要條件,即第二和第三個運算元必須具有相容型別。比較好的做法應該是讓兩者都是 void,因為 void 很難再和其他運算式結合,大大降低被誤用的機會。

由於優先順序非常低,三元運算子不僅能用於函數,連 stream 也照吃不誤。但是如前所述,三元運算子後面兩個運算元必須具有相容型態,遇到 stream 怎麼辦?有一個簡單的修正法,同樣也是藉助運算子優先順序:

namespace debug {
    struct Voidifier {};
    inline void operator&(const Voidifier& unused, std::ostream& ost) {}
}
#ifndef DEBUG_ON
#   define DEBUG_ON     0
#endif
#define DOUT  (!DEBUG_ON)? (void)0 : debug::Voidifier() & std::cerr

DOUT <<  "message" << endl;

還可以進一步做更多有趣的變化,例如在編譯時定義 DEBUG_LEVEL,用以調整輸出的詳細程度:

#define DOUT(level)  (level > DEBUG_LEVEL)? (void)0 : debug::Voidifier() & std::cerr

DOUT(0) <<  "fatal" << endl;
DOUT(3) <<  "warning" << endl;

製作下面這種帶訊息的 assert 也完全不成問題:

inline void operator^(const Voidifier& unused, std::ostream& ost) {
    ost.flush();
    std::abort();
}
#define ASSERT(expr) (!DEBUG_ON || expr)? (void)0 : debug::Voidifier ^ std::cerr \
                    << "** Assertion failed: " #expr ", in " __FILE__  "(" << __LINE__ <<"). "

ASSERT(15 > 51) << "just kidding! \n";

應該有很多人注意到,這樣的做法似乎將原本編譯時期的判斷推移到執行時期,這可能會帶來額外的 overhead。以現代的編譯技術來看,其實這些執行路徑在編譯期即可決定,只要開啟最佳化就不會生成多餘的程式碼。至於 ASSERT 雖然有部分判斷式非得到執行期才有辦法得知,不過判斷 DEBUG_ON 的 || 同樣也是可以在編譯期就確定,因此不會有不必要的判斷。我在 GCC 上做實驗,甚至在 -O0 的狀態下都可以消除這些 overhead。

有時候必須在 debug 做一些更複雜的動作,我看過有人用類似這樣的寫法:

#define DEBUG_CODE(statements) do { statements } while (0)

DEBUG_CODE
(
    long n = 0;
    // ...compute...
    cerr << n << endl;
);

關閉 debug 時可定義成 (void) 0,不過這樣帶來的好處並不明顯比直接用 #ifdef 高就是了。

novus 發表在 痞客邦 PIXNET 留言(2) 人氣()


留言列表 (2)

發表留言
  • edisonx
  • 那份 code 在有人提醒我 #define dprintf // 之後,才發現真的是犯了豬頭般的邏輯錯誤。

    ## 這用法我一直以為它是合法的,參考文件是 n1124.pdf , 6.4.9 Comments (不過可能 C99 不同便是了),妙的是 VC 還蠻常用這東西 (MFC 內部實作也有),日後在寫 C++ 時會避開這個,謝謝您的提出。

    DEBUG_LEVEL 是份有趣的東西,早期想處理但沒研究,用的是懶人無腦方式,所以在 code 裡面會有一堆 if(DEBUG_LEVEL==2)、if(DEBUG_LEVEL==1)... etc ,看完這篇果真收益良多,感謝 :)
  • 我覺得是你誤解了。

    1. 我看了一下你給的參考資料 (n1124-6.4.9),下方的範例明確指出這是不合法的:

    #define glue(x,y) x##y
    glue(/,/) k(); //syntax error, not comment

    2. 同文件的 Translation phases (5.1.1.2) 和 preprocessing-token (6.4 Lexical elements) 基本上與 C++ 相同。也就是說不合法的理由與 C++ 相同

    novus 於 2012/11/14 18:12 回覆

  • edisonx
  • 回頭看文,真的是我誤解了,謝謝指正。