【问题标题】：DEBUG macros in C++C++ 中的调试宏
【发布时间】：2012-12-24 10:25:02
【问题描述】：

我刚刚在 C 中遇到了一个我非常喜欢的 DEBUG 宏

#ifdef DEBUG_BUILD
#  define DEBUG(x) fprintf(stderr, x)
#else
#  define DEBUG(x) do {} while (0)
#endif

我猜 C++ 类似物是：-

#ifdef DEBUG_BUILD
#  define DEBUG(x) cerr << x
#else
#  define DEBUG(x) do {} while (0)
#endif

第二个代码 sn-p 是否类似于 C 中的那个？
您有最喜欢的 C++ 调试宏吗？

编辑： “调试宏”是指“在调试模式下运行程序时可能会派上用场的宏”。

【问题讨论】：

关于您的第二个问题，请阅读FAQ...
有点不相关，但this 可能是一本好书。
@OliCharlesworth 我确实意识到我的第二个问题可能是主观的——但是，我并不是在询问对特定事物的意见，而是在询问 SO 上的编程批次常用的代码示例.但是，如果访问者仍然觉得这个问题不适合 SO，我会确保将其编辑掉。
@Pubby 抱歉不清楚——我的意思是“在调试模式下运行程序时可能有用的宏”
对我来说看起来很完美，会工作

标签： c++ c debugging c-preprocessor

【解决方案1】：

这是我最喜欢的

#ifdef DEBUG 
#define D(x) x
#else 
#define D(x)
#endif

它非常方便，并且可以生成干净（重要的是，在发布模式下快速！！）代码。

到处都是#ifdef DEBUG_BUILD 块（以过滤掉与调试相关的代码块）非常难看，但当你用D() 换几行时还不错。

使用方法：

D(cerr << "oopsie";)

如果这对你来说仍然太丑/怪/长，

#ifdef DEBUG
#define DEBUG_STDERR(x) (std::cerr << (x))
#define DEBUG_STDOUT(x) (std::cout << (x))
//... etc
#else 
#define DEBUG_STDERR(x)
#define DEBUG_STDOUT(x)
//... etc
#endif

（我 suggest 没有使用 using namespace std; 尽管 using std::cout; using std::cerr; 可能是个好主意）

请注意，当您考虑“调试”时，您可能想做更多的事情，而不仅仅是打印到 stderr。发挥创造力，您可以构建能够深入了解程序中最复杂交互的结构，同时让您可以非常快速地切换到构建不受调试工具影响的超高效版本。

例如，在我最近的一个项目中，我有一个巨大的仅调试块，它以FILE* file = fopen("debug_graph.dot"); 开头，然后以点格式导出graphviz 兼容图，以可视化我的数据结构中的大树。更酷的是，OS X graphviz 客户端会在文件发生变化时自动从磁盘读取文件，因此只要程序运行，图形就会刷新！

我还特别喜欢使用仅调试成员和函数来“扩展”类/结构。这开启了实现功能和状态的可能性，这些功能和状态可以帮助您跟踪错误，并且就像包含在调试宏中的所有其他内容一样，可以通过切换构建参数来删除。一个庞大的例程，在每次状态更新时都煞费苦心地检查每个角落案例？不是问题。在它周围拍一个D()。一旦你看到它工作，从构建脚本中删除-DDEBUG，即为发布而构建，它已经消失了，随时可以重新启用以进行单元测试或你有什么。

一个大的、有点完整的例子来说明（可能有点过分）这个概念的使用：

#ifdef DEBUG
#  define D(x) x
#else
#  define D(x)
#endif // DEBUG

#ifdef UNITTEST
#  include <UnitTest++/UnitTest++.h>
#  define U(x) x // same concept as D(x) macro.
#  define N(x)
#else
#  define U(x)
#  define N(x) x // N(x) macro performs the opposite of U(x)
#endif

struct Component; // fwd decls
typedef std::list<Component> compList;

// represents a node in the graph. Components group GNs
// into manageable chunks (which turn into matrices which is why we want
// graph component partitioning: to minimize matrix size)
struct GraphNode {
    U(Component* comp;) // this guy only exists in unit test build
    std::vector<int> adj; // neighbor list: These are indices
    // into the node_list buffer (used to be GN*)
    uint64_t h_i; // heap index value
    U(int helper;) // dangling variable for search algo to use (comp node idx)
    // todo: use a more space-efficient neighbor container?
    U(GraphNode(uint64_t i, Component* c, int first_edge):)
    N(GraphNode(uint64_t i, int first_edge):)
        h_i(i) {
        U(comp = c;)
        U(helper = -1;)
        adj.push_back(first_edge);
    }
    U(GraphNode(uint64_t i, Component* c):)
    N(GraphNode(uint64_t i):)
        h_i(i)
    {
        U(comp=c;)
        U(helper=-1;)
    }
    inline void add(int n) {
        adj.push_back(n);
    }
};

// A component is a ugraph component which represents a set of rows that
// can potentially be assembled into one wall.
struct Component {
#ifdef UNITTEST // is an actual real struct only when testing
    int one_node; // any node! idx in node_list (used to be GN*)
    Component* actual_component;
    compList::iterator graph_components_iterator_for_myself; // must be init'd
    // actual component refers to how merging causes a tree of comps to be
    // made. This allows the determination of which component a particular
    // given node belongs to a log-time operation rather than a linear one.

    D(int count;) // how many nodes I (should) have

    Component(): one_node(-1), actual_component(NULL) {
        D(count = 0;)
    }
#endif
};

#ifdef DEBUG
// a global pointer to the node list that makes it a little
// easier to reference it
std::vector<GraphNode> *node_list_ptr;

#  ifdef UNITTEST
std::ostream& operator<<(std::ostream& os, const Component& c) {
    os << "<s=" << c.count << ": 1_n=" << node_list_ptr->at(c.one_node).h_i;
    if (c.actual_component) {
        os << " ref=[" << *c.actual_component << "]";
    }
    os << ">";
    return os;
}
#  endif
#endif

请注意，对于大块代码，我只使用常规块 #ifdef 条件，因为这在一定程度上提高了可读性，而对于大块，使用极短的宏则更成问题！

N(x) 宏必须存在的原因是指定当单元测试禁用时要添加的内容。

在这部分：

U(GraphNode(uint64_t i, Component* c, int first_edge):)
N(GraphNode(uint64_t i, int first_edge):)

如果我们能说类似的话就好了

GraphNode(uint64_t i, U(Component* c,) int first_edge):

但我们不能，因为逗号是预处理器语法的一部分。省略逗号会产生无效的 C++ 语法。

如果您在不编译调试时有一些额外的代码，您可以使用这种类型的相应逆调试宏。

现在这段代码可能不是“真正好的代码”的例子，但它说明了一些你可以通过巧妙地应用宏来完成的事情，如果你保持自律的话，不一定 邪恶。

我刚刚在想知道 do{} while(0) 的东西之后遇到了this gem，你真的也想要这些宏中的所有花哨！

希望我的示例可以提供一些洞察力，让您了解至少可以做一些聪明的事情来改进您的 C++ 代码。在编写代码时检测代码确实很有价值，而不是在您不了解正在发生的事情时回来执行它。但是，您必须在使其健壮和按时完成之间取得平衡。

我喜欢将额外的调试构建健全性检查视为工具箱中的不同工具，类似于单元测试。在我看来，它们可能会更强大，因为与其将您的健全性检查逻辑放在单元测试中并将它们与实现隔离，如果它们包含在实现中并且可以随意变出，那么完整的测试就不是必需的了因为您可以在紧要关头简单地启用检查并照常运行。

【讨论】：

哇，我从来不知道宏参数（D(x) 中的x）也可以吃<< 和""。能解释多远？听说宏的参数不能包含字符(或)。您能否提供一些关于它的规则/限制参考/链接，好吗？在书中很难找到这样的规则。谢谢。
AFAIK 宏的工作方式是它替换字符串直到语法阻止它这样做。因为括号与替换有关，例如，您将无法嵌入一组不匹配的括号。并且逗号也有牵连（用于分隔宏参数！）。但其他一切都是公平的游戏。谨慎而负责任地使用这些技巧......
永远不要使用像# define D(x)这样的空宏，它们非常危险！正如在 cmets 中对已接受的答案（也存在此问题）所指出的那样，如果您之后错误地忘记了分号，例如 if (x) D(x) i++;，您会得到意想不到的行为，其中 i++ 仅在 x 非零时执行，而它看起来每次都执行。如果你把它写成# define D(x) do { } while(0)，它仍然会被编译器无缝删除，但在缺少分号的情况下会产生编译错误。
你是对的@MarcinTarsier。我会将它添加到我的代码清单中，以使它们更安全。可惜现在丑了点。
这在结构定义中不起作用。结构 { D(int proof_of_initialization;) ... }。在多次尝试打开和关闭调试并移动分号后，我终于选择了简单而危险的#define D(x) x 和#define D(x)。如前所述，这有其问题，但从好的方面来说，它确实有效。

【解决方案2】：

对于问题 1] 答案是肯定的。它只会将消息打印到标准错误流。

对于问题 2] 有很多。我最喜欢的是

#define LOG_ERR(...) fprintf(stderr, __VA_ARGS__)

这将允许在调试消息中包含任意数量的变量。

【讨论】：

是否可以在宏本身中包含换行符 (\n)？

【解决方案3】：

我喜欢使用带有__LINE__、__FILE__ 的宏作为参数来显示打印输出的代码中的where - 在多个位置打印相同的变量名并不少见，所以fprintf(stderr, "x=%d", x); 如果你再往下再添加一个相同的十行，那将没有多大意义。

我还使用了覆盖某些函数并存储调用它的位置（例如内存分配）的宏，以便稍后我可以弄清楚是哪个函数泄漏了。对于内存分配，这在 C++ 中有点困难，因为您倾向于使用 new/delete，并且它们不容易被替换，但是锁定/解锁操作等其他资源可以非常有用地跟踪这种方式 [当然，如果您有一个像优秀的 C++ 程序员一样使用构造/破坏的锁定包装器，您可以将其添加到构造函数中，以便在获得锁后将文件/行添加到内部结构中，并且您可以看到它在其他地方的位置你无法在某处获得它]。

【讨论】：

同意。但是，当 func 可用时，我发现 func 比 FILE 更有用。

【解决方案4】：

第二个代码 sn-p 是否类似于 C 中的代码？

或多或少。它更强大，因为您可以在参数中包含<<-separated 值，因此使用单个参数您会得到需要在 C 中使用可变数量的宏参数的东西。另一方面，有一个很小的机会人们会通过在参数中包含分号来滥用它。甚至会因为调用后忘记分号而遇到错误。所以我会把它包含在一个 do 块中：

#define DEBUG(x) do { std::cerr << x; } while (0)

你有什么喜欢的 C++ 调试宏吗？

我喜欢上面的那个并且经常使用它。我的无操作通常只是阅读

#define DEBUG(x)

这对于优化编译器具有相同的效果。尽管@Tony D 下面的评论是正确的：这可能会导致一些语法错误未被检测到。

我有时也会包含运行时检查，从而提供某种形式的调试标志。正如@Tony D 提醒我的那样，在其中添加 endl 通常也很有用。

#define DEBUG(x) do { \
  if (debugging_enabled) { std::cerr << x << std::endl; } \
} while (0)

有时我也想打印表达式：

#define DEBUG2(x) do { std::cerr << #x << ": " << x << std::endl; } while (0)

在某些宏中，我喜欢包含__FILE__、__LINE__ 或__func__，但这些通常是断言而不是简单的调试宏。

【讨论】：

"我的 no-op 通常只读取 #define DEBUG(x)"... 如果 DEBUG 调用的分号丢失，do-while (false) 替换往往会产生错误，而不是让下一条语句溜走进入 DEBUG 的位置。例如。 “if (expr) DEBUG”，下一行：“++i;”，你会得到“if (expr) ++i;”。更喜欢 do-while 的小理由。很多时候将“<< '\n'”放入宏也是最好的。
@TonyD：好点，更新了我的答案。尽管std::endl 优于'\n'，因为它还刷新了流。
在std::cerr 的情况下，它通常是行缓冲的，所以无论如何都会刷新，使用std::endl 是多余的，但是 - 讨厌 - 困扰我的是人们在流式运营商中使用 std::endl这可能用于std::cout、文件流等 - 严重影响缓冲并可能导致性能显着下降。
assert使用的no-op是((void)0)

【解决方案5】：

我使用下面的代码进行日志记录。有几个优点：

我可以在运行时打开/关闭它们。
我可以编译出特定日志级别的语句。例如，目前，我已经无条件地在 KIMI_PRIVATE 宏中编译，因为我正在调试发布版本中的某些内容，但是由于记录了很多潜在的秘密酱料（哈哈），我将它编译出来发布版本。

多年来，这种模式对我很有帮助。注意：虽然有一个全局的logMessage函数，但代码通常会将日志排队到一个日志线程。

#define KIMI_LOG_INTERNAL(level,EXPR)           \
  if(kimi::Logger::loggingEnabled(level))       \
  {                                             \
    std::ostringstream os;                      \
    os << EXPR;                                 \
    kimi::Logger::logMessage(level ,os.str());  \
  }                                             \
  else (void) 0

#define KIMI_LOG(THELEVEL,EXPR)                 \
  KIMI_LOG_INTERNAL(kimi::Logger::LEVEL_ ## THELEVEL,EXPR)

#define KIMI_ERROR(EXPR)   KIMI_LOG(ERROR,EXPR)
#define KIMI_VERBOSE(EXPR) KIMI_LOG(VERBOSE,EXPR)
#define KIMI_TRACE(EXPR)   KIMI_LOG(TRACE,EXPR)
#define KIMI_INFO(EXPR)    KIMI_LOG(INFO,EXPR)
#define KIMI_PROFILE(EXPR) KIMI_LOG(TRACE,EXPR)

// Use KIMI_PRIVATE for sensitive tracing
//#if defined(_DEBUG)
#  define KIMI_PRIVATE(EXPR) KIMI_LOG(PRIVATE,EXPR)
// #else
// #  define KIMI_PRIVATE(EXPR) (void)0
// #endif

【讨论】：

【解决方案6】：

这是我的版本，使用可变参数模板print 函数：

template<typename... ArgTypes>
inline void print(ArgTypes... args)
{
  // trick to expand variadic argument pack without recursion
  using expand_variadic_pack = int[];
  // first zero is to prevent empty braced-init-list
  // void() is to prevent overloaded operator, messing things up
  // trick is to use the side effect of list-initializer to call a function
  // on every argument.
  // (void) is to suppress "statement has no effect" warnings
  (void)expand_variadic_pack{0, ((cout << args), void(), 0)... };
}

#ifndef MYDEBUG
#define debug_print(...)
#else
#define debug_print(...) print(__VA_ARGS__)
#endif

我的版本使debug_print 成为可变参数模板函数，该函数接受调试级别，允许我选择我想在运行时输出的输出类型：

template<typename... ArgTypes>
inline void debug_print(debug::debug level, ArgTypes... args)
{
  if(0 != (debug::level & level))
    print(args...);
}

请注意print 函数会导致 Visual Studio 2013 Preview 崩溃（我尚未测试 RC）。我注意到它比我之前使用重载operator<< 的ostream 子类的解决方案更快（在Windows 上，控制台输出很慢）。

如果您只想调用一次真正的输出函数（或编写自己的类型安全printf ;-)），也可以在print 中使用临时stringstream

【讨论】：

【解决方案7】：

…并作为所有回复的附录：

就我个人而言，我从不使用像 DEBUG 这样的宏来将调试与发布代码区分开来，而是使用 NDEBUG 这是必须定义发布版本以消除 assert() 调用（是的，我广泛使用assert()）。如果后者没有定义，那么它是一个调试版本。简单！所以，实际上没有理由再引入一个调试宏！（并在DEBUG 和NDEBUG 都未定义时处理可能的情况。

【讨论】：

【解决方案8】：

这是我目前使用的日志宏：

#ifndef DEBUG 
#define DEBUG 1 // set debug mode
#endif

#if DEBUG
#define log(...) {\
    char str[100];\
    sprintf(str, __VA_ARGS__);\
    std::cout << "[" << __FILE__ << "][" << __FUNCTION__ << "][Line " << __LINE__ << "] " << str << std::endl;\
    }
#else
#define log(...)
#endif

用法：

log(">>> test...");

输出：

xxxx/proj.ios_mac/Classes/IntroScene.cpp][gotoNextScene][Line 58] >>> test...

【讨论】：

观察：如当前所示，您始终启用调试。您还将输出限制为 100 个字符（不是很长），但是您不能通过使用 snprintf() 而不是 sprintf() 来确保没有缓冲区溢出。那是危险的生活，不是吗？您的日志不应该转到std::cerr 或std::clog 吗？与其他答案相比，这个答案有什么新的和明显不同的地方？

【解决方案9】：

我用的是跟随微，

#if DEBUG
#define LOGE2(x,y) std::cout << "ERRO : " << "[" << __FILE__ << "][" << __FUNCTION__ << "][Line " << __LINE__ << "] " << x <<":"<< y <<std::endl;
#define LOGI2(x,y) std::cout << "INFO : " << "[" << __FILE__ << "][" << __FUNCTION__ << "][Line " << __LINE__ << "] " << x <<":"<< y << std::endl;
#define LOGD2(x,y) std::cout << "DEBG : " << "[" << __FILE__ << "][" << __FUNCTION__ << "][Line " << __LINE__ << "] " << x <<":"<< y << std::endl;
#define LOGE(x) std::cout << "ERRO : " << "[" << __FILE__ << "][" << __FUNCTION__ << "][Line " << __LINE__ << "] " << x << std::endl;
#define LOGI(x) std::cout << "INFO : " << "[" << __FILE__ << "][" << __FUNCTION__ << "][Line " << __LINE__ << "] " << x << std::endl;
#define LOGD(x) std::cout << "DEBG : " << "[" << __FILE__ << "][" << __FUNCTION__ << "][Line " << __LINE__ << "] " << x << std::endl;
#else
#define LOGE2(x,y) NULL
#define LOGI2(x,y) NULL
#define LOGD2(x,y) NULL
#define LOGE(x) NULL
#define LOGI(x) NULL
#define LOGD(x) NULL
#endif

使用：

LOGE("ERROR.");
LOGE2("ERROR1","ERROR2");

【讨论】：

【解决方案10】：

从其他答案中可以清楚地看出，有很多。有一个我喜欢的，它既允许可变数量的参数，打印参数的名称，还包括一个换行符。

void debug_print() { std::cerr << std::endl; }
template <typename Head, typename... Tail>
void debug_print(Head H, Tail... T) {
    std::cerr << ' ' << H;
    debug_print(T...);
}

#ifdef DEBUGFLAG
#  define DEBUG(...) std::cerr << "dbg  (" << #__VA_ARGS__ << "):", \
                     debug_print(__VA_ARGS__)
#else
#  define DEBUG(...) do {} while(0)
#endif

大部分解释与this answer 相同，但我发现当我想在一行上调试打印多个变量而不使用不同的宏时，额外的模板可以简化它。

【讨论】：