I\'m interested in what purpose various platforms / compilers (\"implementations\") / frameworks assign to the the C and C++ preprocessor macro NDEBUG
The only 'standard' thing about NDEBUG
is that it's used to control whether the assert
macro 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 NDEBUG
macro within a translation unit (source file) using #define
and/or #undef
on NDEBUG
and re-include assert.h
to change how the assert
macro 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.
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.