What Is the Ndebug Preprocessor MACro Used for (On Different Platforms)

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

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.

Why NDEBUG instead of RELEASE?

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.

What's the reason to use DEBUG macro in C++?

Sometimes you don't want to step through the whole code, but just inspect the output in the terminal.

If the code is compiled with DEBUG defined, probably in a debug build, you see the output. For a release build, you don't. If you go to project settings -> Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions, you'll see that DEBUG is defined for the debug build, but it's not for release. (I actually have _DEBUG)

Imagine you have a huge function, and what you're interested in is at the 1000th line (it's old code, can't change it). Would you rather step through all of that messy legacy code or have helpful debug statements at key points? Would you rather the console tell you where something went wrong, or set breakpoints at each of the 237 return statements at fail locations?

Is there a preprocessor macro to detect C99 across platforms?

As per article on Wikipedia on C99

A standard macro __STDC_VERSION__ is defined with value 199901L to indicate that C99 support is available

#if __STDC_VERSION__ >= 199901L
   /*C99*/
#else
  /*Not C99*/
#endif

Preprocessor macro definition of a macro definition

can I rely on this working every time?

Yes.

Is it a standardised feature of the C++ preprocessor (or is it C?)

Both.

it does something like this:

Generally, basically, let's say yes. Macros are expanded upon use. The result of expansion is "rescanned for more macro names to replace", let's say recursively with some special rules.

Identifiers starting with _ and upper case letter are reserved. You can't use _FUNCTION_NAME_ in your code. Use FUNCTION_NAME. See gcc docs on reserved names. You might be interested in how glibc assert.h __ASSERT_FUNCTION did it.

---

Related Topics