3 ms·
Additionally recommended: if attached to a debugger, the program should stop in the debugger, immediately, without printing a message (you can look at the code)
by tom_ 2mo ago
Additionally recommended: if attached to a debugger, the program should stop in the debugger, immediately, without printing a message (you can look at the code), or getting a stack trace (the debugger can do that), or whatever else, to avoid possibly triggering further asserts or causing more problems. This leaves the state just as it was (or as near as feasible), so that it can be investigated.
After being stopped in this way, it must be possible to resume execution somehow. Asserts are code too, and they can be wrong, and it may not be clear why, or what the ramifications might actually be for the specific case - continuing to let the code run can be useful for debugging purposes.
- rramadass 2mo agoThe ASSERT (note caps) macro in Microsoft MFC library does this. It uses a "INT 3" instruction (x86/x64) via "AfxDebugBreak" to invoke the debugger. Since the above is a well-known technique, it has now been generalized and standardized via "std::breakpoint" in C++26 - https://en.cppreference.com/cpp/utility/breakpoint https://en.cppreference.com/cpp/utility/breakpoint This function standardizes many similar existing facilities: __builtin_debugtrap from LLVM, DebugBreak() from Win32 API, __debugbreak Microsoft Specific C/C++ extension, debugger_break from boost.test, assert(false), _asm { int 3 } (MSVC) and asm("int3") (GCC/clang) for x86 targets, etc.