3 ms·
> bugs that have been very difficult to find, as they were 'fixed' by side effects of assert statements and hence didn't show up in debug builds. In those case
by jasode 10y ago
> bugs that have been very difficult to find, as they were 'fixed' by side effects of assert statements and hence didn't show up in debug builds.
In those cases, the assert() was used incorrectly. However, that's not a reason to include the assert code in release builds.
In a similar way, source code will often have troubleshooting code such as:
#if _DEBUG // or #ifndef NDEBUG
std::cerr << "inspect size: " << invoices.size() << std::endl;
// more debugging-related code ...
#endif
Just because some programmers mistakenly put unintended side-effects in between the #if_DEBUG/#endif doesn't mean we want that code in the release builds. The purpose of assert() and _DEBUG is to not include them in release builds.
- marcosdumay 10y agoYou can't change your program without inserting some kind of side effect. It may be timing in a multi thread system, extra memory available for an out of bounds array read, or even the CPU being kept busy and heating up or avoiding yielding to some other program.
- dllthomas 10y agoYour troubleshooting code flushed stderr. That's a side effect, and occasionally it will matter.