IM_DEBUG_BREAK

[noncopyable]

Version/Branch of Dear ImGui:

none

Back-ends:

none

Compiler, OS:

none

Full config/build information:

No response

Details:

i thought i should share this since i had this specific problem and there wasn't anything usefull, then a friend told me about c++26 std::breakpoint and that page had a link to IM_DEBUG_BREAK.

i have a more flexible workaround for this and some impossible cases where you want to enable a breakpoint without halting debugger or adding new code.

/// core.hpp
#ifdef DEBUG
extern int GDB__BREAK;
#endif

/// core.cpp
#ifdef DEBUG
int GDB__BREAK = 0;
#endif

/// in gdb
break file/fn/line... => (breakpoint-id 1)
break file/fn/line... => (breakpoint-id 2)
condition 1 GDB__BREAK==1
condition 2 GDB__BREAK==10

now we can either bind GDB__BREAK to a key or modify it with InputInt, rest should be obvious.

Screenshots/Video:

No response

Minimal, Complete and Verifiable Example code:

No response

[ocornut]

You can programmatically perform the check to not have to rely on debugger-provided condition or features. e.g.

if (GDB__BREAK == 1)
    printf(""); // <--- put breakpoint here or call IM_DEBUG_BREAK();

Assuming support for live update of C++ code (edit & continue, live++ etc.) you can add complex conditional breakpoints in a live app anywhere.

I frequently use keyboard modifiers as way to activate a breakpoint:
https://github.com/ocornut/imgui/wiki/Developer-Tips#using-breakpoints

[Peter0x44]

@noncopyable could #7266 be a fix to the issue you were speaking of?

[noncopyable]

hello @Peter0x44.
the problem i was trying to solve was not specific to imui or IM_DEBUG_BREAK. ideally i needed a way to add breakpoints without halting debugger or modifying the code. not sure about other debuggers but for gdb "adding" was not possible. the workaround i found was the second best, not adding but conditionally enabling a breakpoint any time of my chosing and it is not easily expressible as a gdb condition-function. this is the best method i could think of. seeing IM_DEBUG_BREAK mentioned on an article about std::breakpoint i thought this macro was trying to address similar use-cases, so i had to share :)
as far as i understand #7266 is not related

hello @ocornut.
edit & continue, livecoding... i wish :)
feel free to close the issue. those that have the same problem now can search IM_DEBUG_BREAK or std::breakpoint and this might pop as a workaround.

[ocornut]

Closing as answered. Thank you both for your feedback.
Honestly I feel bad for those of you needing to use GDB.
Hopefully eventually RemedyBG or RAD Debugger will be ported to other systems than Windows.

[ocornut]

(keeping on the off-topic derailment, I'm still using Visual Studio myself, but those new debuggers have interesting features see, e.g. https://www.youtube.com/watch?v=r9eQth4Q5jg)

https://remedybg.itch.io/remedybg

https://github.com/EpicGames/raddebugger
RAD Debugger is more likely to come to Linux sooner.

[Peter0x44]

Yeah, gdb is unfortunately a bit more flaky and unreliable than it should be. It's completely serviceable, and I don't mind using it, but much better is possible.

Python is also one thing I don't like about gdb. Libstdc++ specifically ships some python scripts that are required to usably print say, an std::string.

Certain features of gdb are quite slow, like the breakpoint conditions.

The remedybg author specifically wrote in some issue that he didn't want to port to Linux so it will likely never be an option. Rad debugger isn't there yet, but I'm waiting eagerly.

[noncopyable]

keeping on the off-topic derailment

do not taunt me. if i start ranting (with this terrible english) on the sorry state of this ape world we call programming, i would be banned on github as well :)