On Wed, 5 Jan 2022 at 11:46, Timur Doumler via SG15 <sg15_at_[hidden]>
wrote:

>
> > On 5 Jan 2022, at 11:03, Daniel Ruoso via SG15 <sg15_at_[hidden]>
> wrote:
> > I think this is a crucial point.
> >
> > It's not clear to me what a breakpoint outside of a debugger would do.
>
> I would expect that it does nothing, or perhaps that the behaviour is
> implementation-defined. In practice, I’d probably define an assertion macro
> where I do some logging, then check if (std::is_debugger_attached) and then
> do std::breakpoint if true.
>

The proposal is that std::breakpoint includes the "is debugger attached"
check, so you just use std::breakpoint() and it does nothing if not being
debugged (or if the debugger is attached in some way that the
implementation cannot detect). So you wouldn't need to check
std::is_debugger_attached() explicitly.

Ben suggested adding an unconditional breakpoint, which would not do the
check (and presumably you wouldn't want to use std::is_debugger_attached()
before it, because doing so would make it equivalent to the conditional
one, and not solve the problem for implementations that can't detect a
debugger). Although since the <debugging> header isn't currently proposed
to be freestanding, maybe that's less of an issue.




> If this is not the intended use, I’d be curious to hear what one should do
> instead.
>