Re: dbg_break macro

On 06/06/2024 22:40, Thiago Adams wrote:

On 06/06/2024 17:10, Blue-Maned_Hawk wrote:

>
I feel like you would probably want to be using a debugger to set your
breakpoints, although the Clang dialect of C does have a
__builtin_debugtrap builtin subroutine.
>

And gcc has __builtin_trap, which will have a similar effect.

>
>

  C++ 26 will have breakpoint. Lot of links about how to do that.
https://en.cppreference.com/w/cpp/utility/breakpoint
 But, thinking about my usage, the source line, message, etc., everything that assert has is useful. What is not useful is to pass a constant expression for something that is supposed to be a runtime check.
 I remember when I thought that static_assert could just be assert because it is not hard for the compiler to know when we have a constant expression or not. If we have a constant expression, this should be just like static_assert.

A major point (for me, at least) about static_assert is that it is /always/ compile-time.  Thus I know it never has any run-time overhead.
I have also used macros that make use of gcc's "__builtin_constant_p()" function so that the compiler checks at compile-time if it can, regardless of any debug options, but won't normally add any run-time checks unless I am setting options to check for some specific issue.

 assert(2 == 2); // compile-time check
 If the expression is not constant, then it would be checked at runtime during debugging.
 This idea fails fast, when we think assert is used with assert(0);

Personally, I can't see any use for an assertion that is always known to fail.  It makes no sense to me - it's a claim "this statement is not true".  I have no problem with having checks and handling situations that should never occur, especially during development and testing phases of the program.  But the appropriate response might be to reset the board, invoke the debugger, log an error message and restart, halt and catch fire, or panic, and the macro or function should reflect that.   Simply denying reality and fundamental logic by declaring that 0 is true is /not/ an appropriate response.

 I think dbg_break also transmit the idea that the branch is possible while assert(0) can be confusing.
 

Certainly dbg_break is a better name, IMHO.  But I'd want a reason for the halt, especially if you are not running the code under a debugger at the time.