C++ _DEBUG 与 NDEBUG

_DEBUG vs NDEBUG

提问by deft_code

Which preprocessor define should be used to specify debug sections of code?

应该使用哪个预处理器定义来指定代码的调试部分？

Use #ifdef _DEBUGor #ifndef NDEBUGor is there a better way to do it, e.g. #define MY_DEBUG?

使用#ifdef _DEBUG或者#ifndef NDEBUG或者有没有更好的方法来做到这一点，例如#define MY_DEBUG？

I think _DEBUGis Visual Studio specific, is NDEBUG standard?

我认为_DEBUG是 Visual Studio 特定的，是 NDEBUG 标准吗？

采纳答案by Christoph

Visual Studio defines _DEBUGwhen you specify the /MTdor /MDdoption, NDEBUGdisables standard-C assertions. Use them when appropriate, ie _DEBUGif you want your debugging code to be consistent with the MS CRT debugging techniquesand NDEBUGif you want to be consistent with assert().

Visual Studio 定义_DEBUG当您指定/MTdor/MDd选项时，NDEBUG禁用标准 C 断言。在适当的时候使用它们，即_DEBUG如果您希望您的调试代码与MS CRT 调试技术一致，并且NDEBUG如果您希望与assert().

If you define your own debugging macros (and you don't hack the compiler or C runtime), avoid starting names with an underscore, as these are reserved.

如果您定义自己的调试宏（并且您没有破解编译器或 C 运行时），请避免以下划线开头的名称，因为这些是保留的。

回答by bruziuz

Is NDEBUG standard?

NDEBUG 是标准的吗？

Yes it is a standard macro with the semantic "Not Debug" for C89, C99, C++98, C++2003, C++2011, C++2014 standards. There are no _DEBUGmacros in the standards.

是的，它是一个标准宏，具有 C89、C99、C++98、C++2003、C++2011、C++2014 标准的语义“Not Debug”。_DEBUG标准中没有宏。

C++2003 standard send the reader at "page 326" at "17.4.2.1 Headers" to standard C.

C++2003 标准将“17.4.2.1 标题”处“第 326 页”的阅读器发送到标准 C。

That NDEBUG is similar as This is the same as the Standard C library.

那 NDEBUG 类似于 这与标准 C 库相同。

In C89 (C programmers called this standard as standard C) in "4.2 DIAGNOSTICS" section it was said

在 C89（C 程序员将此标准称为标准 C）中的“4.2 诊断”部分中说

http://port70.net/~nsz/c/c89/c89-draft.html

If NDEBUG is defined as a macro name at the point in the source file where is included, the assert macro is defined simply as

     #define assert(ignore) ((void)0)

http://port70.net/~nsz/c/c89/c89-draft.html

如果 NDEBUG 在源文件中包含的点处定义为宏名称，则断言宏定义为

     #define assert(ignore) ((void)0)

If look at the meaning of _DEBUGmacros in Visual Studio https://msdn.microsoft.com/en-us/library/b0084kay.aspxthen it will be seen, that this macro is automatically defined by your сhoice of language runtime library version.

如果查看_DEBUGVisual Studio https://msdn.microsoft.com/en-us/library/b0084kay.aspx中宏 的含义， 则会发现该宏是由您选择的语言运行时库版本自动定义的。

回答by Adrian McCarthy

I rely on NDEBUG, because it's the only one whose behavior is standardized across compilers and implementations (see documentation for the standard assert macro). The negative logic is a small readability speedbump, but it's a common idiom you can quickly adapt to.

我依赖NDEBUG，因为它是唯一一个跨编译器和实现标准化的行为（请参阅标准断言宏的文档）。否定逻辑是一个小的可读性障碍，但它是您可以快速适应的常见习语。

To rely on something like _DEBUGwould be to rely on an implementation detail of a particular compiler and library implementation. Other compilers may or may not choose the same convention.

依赖类似的东西_DEBUG就是依赖特定编译器和库实现的实现细节。其他编译器可能会也可能不会选择相同的约定。

The third option is to define your own macro for your project, which is quite reasonable. Having your own macro gives you portability across implementations and it allows you to enable or disable your debugging code independently of the assertions. Though, in general, I advise against having different classes of debugging information that are enabled at compile time, as it causes an increase in the number of configurations you have to build (and test) for arguably small benefit.

第三种选择是为您的项目定义自己的宏，这是非常合理的。拥有自己的宏可为您提供跨实现的可移植性，并允许您独立于断言启​​用或禁用调试代码。不过，一般来说，我建议不要在编译时启用不同类别的调试信息，因为它会导致您必须构建（和测试）的配置数量增加，而这可以说是很小的好处。

With any of these options, if you use third party code as part of your project, you'll have to be aware of which convention it uses.

使用这些选项中的任何一个，如果您使用第三方代码作为项目的一部分，您必须了解它使用的约定。

回答by Jonathan Leffler

The macro NDEBUG controls whether assert() statements are active or not.

宏 NDEBUG 控制 assert() 语句是否处于活动状态。

In my view, that is separate from any other debugging - so I use something other than NDEBUG to control debugging information in the program. What I use varies, depending on the framework I'm working with; different systems have different enabling macros, and I use whatever is appropriate.

在我看来，这与任何其他调试是分开的——所以我使用 NDEBUG 以外的东西来控制程序中的调试信息。我使用的内容会有所不同，具体取决于我使用的框架；不同的系统有不同的启用宏，我使用任何合适的。

If there is no framework, I'd use a name without a leading underscore; those tend to be reserved to 'the implementation' and I try to avoid problems with name collsions - doubly so when the name is a macro.

如果没有框架，我会使用没有前导下划线的名称；那些倾向于保留给“实现”，我尽量避免名称冲突的问题 - 当名称是宏时更是如此。

回答by Earlz

Be consistent and it doesn't matter which one. Also if for some reason you must interop with another program or tool using a certain DEBUG identifier it's easy to do

保持一致，哪个都无关紧要。此外，如果由于某种原因您必须使用某个 DEBUG 标识符与另一个程序或工具进行互操作，这很容易做到

#ifdef THEIRDEBUG
#define MYDEBUG
#endif //and vice-versa

回答by James

Unfortunately "DEBUG" is overloaded heavily. For instance, it's recommended to always generate and save a pdb file for RELEASE builds. Which means one of the -Zx flags, and -DEBUG linker option. While _DEBUG relates to special debug versions of runtime library such as calls to malloc and free. Then NDEBUG will disable assertions.

不幸的是，“调试”严重超载。例如，建议始终为 RELEASE 构建生成并保存 pdb 文件。这意味着 -Zx 标志之一和 -DEBUG 链接器选项。而 _DEBUG 与运行时库的特殊调试版本有关，例如对 malloc 和 free 的调用。然后 NDEBUG 将禁用断言。