Menu
The standard C assert macro is disabled when the macro NDEBUG is defined, meaning "Not debug". This leads to really awful double negative cases like #ifndef NDEBUG //DebuggingCode #endif. It seems like RELEASE would have been a better choice of terms, but I can't believe the standards committee would have done it that way without some reason to do so....
324
Save this answer. Show activity on this post. 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.
Yes it is a standard macro with the semantic "Not Debug" for C89, C99, C++98, C++2003, C++2011, C++2014 standards.
The macro NDEBUG controls how assert behave.
You should typically NOT use it for anything else. If you would use it for other things, like extra debug trace output, you don't have the option to build your application without this extra code but with assertions enabled.
I would recommend that you define your own preprocessor symbol, say MY_TRACE, and use it. Also, define it to 0 or 1 and use #if MY_TRACE. That way you could catch files using the symbol without being properly initialized, if you configure your compiler to issue a warning when using an uninitialized variable in a preprocessor expression.
138
Having a macro RELEASE implies that the code is ready for distribution - when it may not. NDEBUG on the other hand implies that debugging is complete, hence ready for testing.
I also suppose that having to turn things off is better than having to make sure that you have turned everything on. That is why most OSs (for example) have most things switched on when a lot of people do not need it.
Just my humble thoughts.
20
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
