NDEBUG 预处理器宏的用途是什么（在不同平台上）？
我感兴趣的是各种平台/编译器（“实现”）/框架分配给 C 和 C++ 预处理器宏 NDEBUG 的目的。
C 以及 C++ 标准仅提到此定义一次，即控制 assert() 宏的行为。
我要求仅包含具体答案，您知道C或C++的某个平台/框架/库使用NDEBUG定义来除了标准定义的 assert() 宏之外，启用或禁用其他任何内容。
提出这个问题的原因之一是 MS (Visual-C++) 总是（？）使用“他们的”_DEBUG 定义来区分调试和发布内容，我想知道这是否是库/平台的常见做法他们的“自己的”调试定义或其他库/平台是否使用 NDEBUG 来进行与调试相关的内容。
I'm interested in what purpose various platforms / compilers ("implementations") / frameworks assign to the the C and C++ preprocessor macro NDEBUG.
The C as well as the C++ standard only mention this definition once, namely to control the behavior of the assert() macro.
I would ask to include only specific answers, where you know that a certain platform / framework / library for C or C++ uses the NDEBUG definition to enable or disable anything else in addition to the standard defined assert() macro.
One reason for asking this question has been that MS (Visual-C++) always(?) uses "their" _DEBUG define to distinguish between debug and release stuff and I was wondering if this is a common practice for a library / platform to have their "own" debug define or whether other libraries / platforms use NDEBUGfor their debug related stuff.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
NDEBUG唯一的“标准”之处是它用于控制assert宏是否扩展为执行检查的内容。 MSVC 通过在项目中定义此宏，有助于在发布构建配置中定义此宏。您可以通过编辑项目配置来手动更改它。其他工具链可能（也可能不会）做类似的事情。请注意，您还可以使用
#define和/或#undef更改翻译单元（源文件）内的NDEBUG宏的状态NDEBUG并重新包含assert.h以更改assert宏的行为方式（打开和关闭它）。该行为是标准强制执行的，并且是标准允许第二次包含标准标头以更改第二次包含后的编译行为的唯一一次（我认为）。The only 'standard' thing about
NDEBUGis that it's used to control whether theassertmacro will expand into something that performs a check or not. MSVC helpfully defines this macro in release build configurations by defining it in the project for you. You can change that manually by editing the project configuration. Other toolchains might (or might not) do something similar.Note that you can also change the state of the
NDEBUGmacro within a translation unit (source file) using#defineand/or#undefonNDEBUGand re-includeassert.hto change how theassertmacro behaves (turn it on and off). That behavior is mandated by the standard, and is the only time (I think) where the standard permits including a standard header a second time to change the behavior of compilation after the second inclusion.这是由相关框架的维护者决定的。由于此类决定可能会发生变化，因此您不应该依赖它。我使用 NDEBUG 作为与调试相关的所有内容（例如跟踪输出）的切换开关，但我可能会在下一个版本中改变主意。任何人都无法在这里给出答案来替代检查您在给定项目中使用的框架的 API 文档。
话虽这么说，在库/框架标头中使用 NDEBUG，对于除
assert()之外的任何其他内容，将是一个相当愚蠢的设计决策。应用程序员可以明确设置/取消设置 NDEBUG，但是他认为合适，在包含任何库或框架的标头之前和/或之后，因此库/框架维护者不能依赖于设置 NDEBUG对于发布库或未设置调试库。我怀疑任何重要的项目都会以这种方式依赖 NDEBUG。That is a decision up to the maintainer(s) of the framework in question. Since such decisions are subject to change, it's nothing you should rely on. I use NDEBUG as a toggle for everything debug-related (e.g. trace outputs), but I might change my mind in the next release. No answer anyone could give here is a replacement for checking the API documentation of the frameworks you use in a given project.
That being said, using NDEBUG in library / framework headers, for anything else but
assert(), would be a rather dumb design decision. The application programmer is explicitly allowed to set / unset NDEBUG however he sees fit, before and / or after including the headers of any library or framework, so the lib / framework maintainer could not rely on NDEBUG being set for a release lib or not set for a debugging lib. I doubt any significant project would have relied on NDEBUG that way.