Date: Tue, 26 Aug 2025 14:23:36 +0300
On Sun, 24 Aug 2025 at 23:15, Adrian Johnston via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> I would argue there has to be support by default for making the debugger stop on the exact line where the assert fired. There is just no excuse for having a software engineer do unnecessary manual labour every time an assertion fires. And students shouldn't be asked to write this themselves when learning a new language. Currently only clang (and not gcc) can be configured to support this perfectly.
I can certainly entertain having the default contract violation hander
invoke breakpoint_if_debugging() in GCC.
> There are also uses for having different "levels" of severity when it comes to asserts. When I am cross compiling to an embedded target I am not going to be able to afford all the same assertions with all the same strings being added to the string table. At minimum that entails "debug asserts" and "release asserts" to differentiate between the two use cases. The code I am sharing also uses compile time string hashing in order to identify filenames when compiled for release. (This didn't work reliably with constexpr and you have to check the generated assembly to find that out.) Having these kinds of build levels is also common enough that CMake has it built in.
This paper https://wg21.link/p3400 should give you that, and more.
> Next is the issue of formatting assert messages. It turns out to be really handy to have debug asserts that take C-style variadic arguments and perform printf formatting. There is an issue here with having untested format strings and that does need to be resolved. However, by leveraging gcc's ability to check a printf format string against its arguments I was able to avoid any issues in my own work. This approach avoids making an unnecessary local function call or allocating memory after an assertion fails.
That has been discussed as a recognized shortcoming of C++26
contracts. We'll eventually get to discussing some sort of a solution.
<std-proposals_at_[hidden]> wrote:
> I would argue there has to be support by default for making the debugger stop on the exact line where the assert fired. There is just no excuse for having a software engineer do unnecessary manual labour every time an assertion fires. And students shouldn't be asked to write this themselves when learning a new language. Currently only clang (and not gcc) can be configured to support this perfectly.
I can certainly entertain having the default contract violation hander
invoke breakpoint_if_debugging() in GCC.
> There are also uses for having different "levels" of severity when it comes to asserts. When I am cross compiling to an embedded target I am not going to be able to afford all the same assertions with all the same strings being added to the string table. At minimum that entails "debug asserts" and "release asserts" to differentiate between the two use cases. The code I am sharing also uses compile time string hashing in order to identify filenames when compiled for release. (This didn't work reliably with constexpr and you have to check the generated assembly to find that out.) Having these kinds of build levels is also common enough that CMake has it built in.
This paper https://wg21.link/p3400 should give you that, and more.
> Next is the issue of formatting assert messages. It turns out to be really handy to have debug asserts that take C-style variadic arguments and perform printf formatting. There is an issue here with having untested format strings and that does need to be resolved. However, by leveraging gcc's ability to check a printf format string against its arguments I was able to avoid any issues in my own work. This approach avoids making an unnecessary local function call or allocating memory after an assertion fails.
That has been discussed as a recognized shortcoming of C++26
contracts. We'll eventually get to discussing some sort of a solution.
Received on 2025-08-26 11:23:53