我正在研究由其他人构建的C ++程序,并且看到了很多像这样的DEBUG用途
#ifdef DEBUG
cout << "Value is "<< value << endl;
#endif
我自己仍处于学习过程中,成为一名富裕的C ++程序员,我主要使用Visual Studio和断点进行调试。所以我想知道,如果我能够逐步调试代码来调试值,还有其他原因可以使用这些宏吗?
尝试谷歌但没有找到太多有用的网页。
感谢。
答案 0 :(得分:10)
有时您不想单步执行整个代码,只需检查终端中的输出。
如果代码是使用DEBUG
编译的,可能是在调试版本中,您会看到输出。对于发布版本,您不需要。如果您转到项目设置 - &gt;配置属性 - &gt; C / C ++ - &gt;预处理器 - &gt;预处理器定义,您将看到为调试版本定义了DEBUG
,但它不是为了发布。 (我实际上有_DEBUG
)
想象一下,你有一个巨大的功能,你感兴趣的是第1000行(它的旧代码,不能改变它)。您是否愿意逐步完成所有混乱的遗留代码或在关键点处获得有用的调试声明?您是否宁愿控制台告诉您哪里出了问题,或者在失败位置的237 return
个语句中设置断点?
答案 1 :(得分:6)
在进行调试时,通常会在屏幕上转储一些中间值。视觉调试器并不总是有帮助,因为你浪费了很多时间用鼠标进行操作。
“文本模式调试”和日志记录的需求也经常来自嵌入式系统体验,在这种体验中,您没有太多的视觉辅助,您所能做的就是将一两个字节转储到串口或类似的东西那。当您习惯于快速查找关键调试点时,只需插入一些打印代码,其值将检查程序的正确性。
当您的项目在调试模式下编译时,“DEBUG”宏由MSVC ++编译器定义。当你制作Release版本时,所有对最终用户来说实际上无用的代码都会被预处理器“剥离”。
典型代码段
#ifdef DEBUG
Some code
#endif
如果未定义DEBUG,预处理器将删除。
答案 2 :(得分:3)
使用控制台输出而不是调试器来识别多线程错误可能很方便。通过断点中断程序流程通常会阻止错误发生,因为它会阻止线程踩到彼此的脚趾。其他基于时序的错误也是如此。
答案 3 :(得分:2)
“我主要使用Visual Studio和断点进行调试”
在某些情况下,通过逐步观察其行为来调试代码非常困难甚至是不可能的。有时创建这种“调试输出”会更容易,这样您就可以看到这些日志中发生了什么,而不是试图实时地逐步执行它。
检查是否定义了DEBUG
符号是为了确保您的发行版本不会产生这种输出。请注意,Visual Studio为调试配置定义了 _DEBUG
。更具体地说:“当您指定/ MTd或/ MDd选项时,编译器定义_DEBUG
。这些选项指定C运行时库的调试版本。”
还有NDEBUG
在定义时禁用C样式断言。有关详细信息,请查看_DEBUG vs NDEBUG。
答案 4 :(得分:1)
用于调试,通过将代码包装在预处理器命令中,您可以打开或关闭该代码。
答案 5 :(得分:1)
很简单,如果你想获得一些可以帮助你进行“软”调试的消息,你只需定义DEBUG,#ifdef DEBUG
和#endif
之间的句子就会生效,在你的情况下得到一些有用的信息。
这样,当你完成开发并想要发布时,你只需取消定义调试,消息就不会再出现了。
您可能认为是的,这是一个好主意,但是应用程序的代码更多,但好处是那些是宏并且在编译时进行评估,因此,如果您删除所有应用程序将是相同的他们:)
答案 6 :(得分:0)
我建议不要使用DEBUG
宏。相反,使用标准的NDEBUG
宏,它是在不需要调试代码时定义的,而不是在需要调试代码时定义的。也就是说,默认情况下调试代码是活动的。您会发现只有一小部分性能关键代码需要关闭调试检查才能获得足够的性能。