|Pedigree of NDEBUG and assert()?||nolo...@gmail.com||1/28/13 3:02 PM|
I'm probably going way back in time here, but I have some questions about NDEBUG. I hope there are some folks who remember when these topics and concepts were being discussed by the committee(s).
What was the motivation for NDEBUG?
How was it envisioned to be used or mapped onto configurations (for example, Debug and Release).
Why was DEBUG never ackowledged?
What was the motivation for assert()?
How was assert() envisioned to be used?
And finally, a deeper philosophical question. I hope it does not stir up too much commotion:
If there are two configurations - Debug (!NDEBUG) and Release (NDEBUG) - is it appropriate for production or release code to *not* define NDEBUG and use assert() to call abort()? Remember, I'm asking in the context of production software running live - like a DNS Bind server or an Apache Web server.
I have my opinions, but I'm going to withhold them so I don't taint folks. Thanks in advance for any insight.
|Re: Pedigree of NDEBUG and assert()?||Andrzej Krzemieński||2/4/13 4:01 AM|
I do not think the C++ Committee had to ever consider the semantics of assert() and NDEBUG. Having it in C++ is a consequence of the decision to provide the same (within reason) standard library that C provides. In consequence, you should be asking this question on C language forums.
My personal answer to your question is: you have the tool with well-defined semantics. You know what it can do. You make the call how to use it. The behavior of assert() that fails is similar to Undefined Behavior: it may call abort(), it may not even be checked: you never know. So you should use it in the way that assertion never fails. If you follow this rule (which is virtually impossible), the question whether a failing assert aborts is secondary.
I personally do not tie the defining macro NDEBUG with release builds, and sometimes deliberately choose to keep it defined in release modes.