Exception (and thread) safety/awareness of hello_imgui question about hello_imgui

[pthom]

Hello,

hello_imgui does not use exceptions and does not make any assumptions about them being present or not. So I guess you can do whatever you like.

I consider it as a kind of window management system for Imgui that hides some its mechanics

Yes.

P.S. It would be worth to mention about thread safety/awareness too.

hello_imgui does not launch any thread at all.

[MichaelKv]

Thanks. To be able to use exceptions (and C++ does use them by default itself) or threads I must be sure the environment allows it. Imgui is almost a plane C library that does nothing about such support but it allows access to all the internals and do not have (or do not have many) callbacks that may throw. But as far as hello_imgui hides some internals and is built around the users’ callbacks (as I see from hello_world example) it shall provide exception safe guarantees or be aware about exceptions (allow a user somehow handle them and make hello_imgui intact). The same is valid about thread safeness – you are either thread safe or aware about threads (i.e. you provide some synchronization primitives that your clients may use).
I do have to wrap some Imgui code with my own thread/exception safe wrappers and this is OK though it means Imgui may not be used in real-life applications as is. But hello_imgui is a kind of wrapper itself and to have a wrapper around a wrapper…

hello_imgui does not launch any thread at all.

I do understand it. But the real applications inevitably do and your clients must know what to expect and how use hello_imgui in multi-threaded environment with exceptions.
In other words, your clients have to decide whether to use hello_imgui or write their own window management system (as I believe all them do for pure Imgui). I am not an expert in GUI applications and it is hard for me to estimate such cases myself so I rely on documentation heavily.

[pthom]

If you look at the API overview, you will see these callbacks:

And these functions:

What HelloImGui::Run() will do is simply:

• Init the backend and imgui
• launch a render loop (at approx 60 FPS) that will run on the application's main thread (more precisely the thread where HelloImGui::Run was called).
• This render loop will handle frames creation and call a combination of the callbacks (depending on the UI state) synchronously at each loop
• HelloImGui::Run() will finish execution only after the application window was closed.

The wording "callback" is thus perhaps not quite appropriate, but be assured that these callbacks are synchronous.

So in summary,

• hello-imgui does not make any exception safety guarantee, not anymore than imgui. However it does not launch any exception.
• If the code of the user provided callbacks may throw, then either (1) the user should add a catch clause in the callback that will catch them, or (2) HelloImGui::Run will throw them synchronously in the application main thread. Option (1) is of course the better choice.
• hello-imgui guarantees that at any given time, only one thread will be active inside hello-imgui (and in fact it does not create any thread).
• if callbacks need to access data that could be updated by a separate thread (for example a camera thread that would update a video image), the user is responsible to protect the access to this data (via mutex, atomics, ...)

[MichaelKv]

Ok, thank you. I see that in case of an error I have to invent some program behavior that would not crash the program. I cannot just throw an exception and stop thinking about the broken frame anymore. I can wrap the Imgui’s begin/end C-style paradigm with my own exception safe helpers but hello_imgui looks different and I am not sure I could use it the same way.
I wonder if there is a window manager for Imgui for C++ (the full-featured C++ with exceptions, threads, co-routines in the future, etc.)

[pthom]

I cannot just throw an exception and stop thinking about the broken frame

Well, the callbacks that you provide are supposed to be consisting of mainly only GUI code (I.e ImGui calls). The business code should belong elsewhere, as for any program where the GUI is separated from the rest. You could plug signals and slots between callbacks and your business code for example (using Qt or boost::signal)