What is the NDEBUG preprocessor macro used for (on different platforms)?
Asked Answered
H

2

42

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.

Hooky answered 29/3, 2011 at 13:46 Comment(1)
The link to the MSDN page is now dead. Archive URL: web.archive.org/web/20110412105153/http://msdn.microsoft.com/…Dismal
F
29

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.

Fibre answered 29/3, 2011 at 16:24 Comment(0)
M
34

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.

Mutation answered 29/3, 2011 at 14:37 Comment(1)
Thanks. This is a useful clarification. It doesn't answer however whether/if it is used by some platforms/libraries for something else. (I think its not used for anything else (than assert()) in MSVC, but I'm not even sure of this.)Hooky
F
29

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.

Fibre answered 29/3, 2011 at 16:24 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.